郑重声明：本文纯属Fans同学的个人见解，仅供参考，欢迎拍砖。
不带任何感情色彩，无论是讽刺、褒扬，还是抱怨、感叹,纯属读者的个人感觉,与Fans无关。
软林至尊，Fans同盟。号令天下，莫敢不从。 @Fans.Lei
问题背景
1.在学校，做一个项目，从需求设计到编码测试，基本上都由自己一个人完成，不存在团队合作和分工，也不存在和其他人冲突的问题。
2.需求中遇到了问题，自己可以决断，想怎么做就怎么做。
3.大多不需要和其他人沟通。
总之，在学校基本上是一个人单干，到了公司要团队开发，需要一个转变和适应的过程。
5大问题及解决方案
1.团队合作
1.1如何分工
分工和合作是辩证统一的。
划分每个人的职责和任务是合作的基础。
项目前期，“一个任务”被划分给了别人，后来又“划分给了我”。经过解释，发现这个任务“本来就是我的”，出现这种问题，主要是前期相关人员都理解错了。今后还会出现这种情况么？如何避免？
1.2如何合作
模块之间既相对独立，又相互依赖。
接口提供者想改变接口，接口依赖方该怎么做呢。不让他改变，还是他变了，我去修改相关代码？
解决方案：
模块之间的依赖，应该由双方共同探讨和制定，不能随意修改，一旦修改，要及时通知对方。
分工，一定要及时确认职责。
2.需求问题
2.1需求不明确
项目前期，需求不够明确，很多时候都根据自己的理解去做，结果与需求不完全一致了。
2.2需求和开发的关系
开发人员要严格按照需求来做，如果需求不合理，开发人员应该提出来。
问题：如何去判断？
解决方案：
和需求分析师及团队领导沟通；积累经验。
3.沟通不畅
3.1沟通意识
在学校"单干"惯了，遇到问题习惯独自去想，而没有去和相关人员沟通。
3.2沟通对象
遇到问题，不知道应该和谁沟通，项目前期有此困惑。
3.3距离
项目前期，团队成员分在3个地方，使用在线沟通工具不够方便，说不清。
3.4工作中有情绪
有时比较急躁，不够耐心，主要集中在项目中期，模块整合过程中。
3.5沟通技巧
用词不当，引起他人不快。
解决方案：
沟通遇到问题，应当及时自我反省，并和团队领导沟通，而不是置之不理。
4.代码重复
4.1界面重复
比如，分页栏那一块完全一致。
4.2代码重复
类似的功能大量出现，比如事务，获取数据库连接，分页算法。
4.3思想和架构重复
不同模块的架构尤其是Java这块，几乎完全一致。
解决方案：
不同模块之间的重复，多人共同制定一个标准，然后按照标准去做。
同一模块之间的重复，可以使用类的继承，提取工具类，设计模式减少冗余代码，也可以使用Hibernate等框架。
5.个人思想在某些方面比较保守，追求稳定，不想改变
5.1传递数字活动
沟通培训那个传递数字的活动，最开始小组成员已经确定了一个方案，后来小路提出了另外一种方案，我当时并没有赞成。其他人大多也没有赞成，因为短时间内完全改变一种方案，有难度，也不想改变。
5.2 SVN和Maven
项目最开始开发时，并没有采用SVN管理源代码，也没有采用Maven管理项目依赖和打包部署。
后来，为了方便集成和部署，迅速学习和使用SVN及Maven。
解决方案：
如果可能，积极参与和推动团队意见和方案的形成。如果自己观点和团队观点冲突较大，保留自己的意见。
感言：在团队合作开发的情况下，树立沟通意识，及时沟通并且通过沟通形成一个 结论，两者即沟通过程和形成结论都非常重要。 遇到问题不可怕，关键在于解决问题的方法。
