曾有1些好友和同事问我： 伴随着团队人数的增加，怎样样能让全部团队的产出是 1+1 >2？ 最少也是 1+1 = 2 。
结合我本身的1些角度和经验，我给出了我的1些想法和做法。
(这里的角度是从实际开发中合作的角度来斟酌的，提升薪资1般能在很大程度上提升战力 ^^, 这个不在本篇的讨论范围)
之前看过1本书， 书中说了这样1个寓言-- “巴比伦通天塔”
内容大概是：人类希望能联合起来建立通往天堂的高塔。为了禁止人类的计划，上帝让人类说不同的语言，令人类相互之间不能沟通，计划因此失败，人类自此各散东西。
这里的统1的团队“语言”，只的是环境和编码上的1些习惯和规定。细部可以是：
1. 统1的规格文档
项目不管多少人做，规格文档总是需要的， 只是情势和标准上会有1些不同。
比较小的项目， 人比较少， 可以斟酌在 Wiki 上来写规格。情势也可能比较随机。 但是对触及人数比较多， 项目较大的状态，规范的规格文档就会比较重要。SA, SD , AP, QA 都需要能看得懂。 规格同样成为大家交换语言的"教材"。 设计1个好的规格文档的模板也就相当重要。
2. 统1的集成开发环境。
对 Java 开发者来讲，Eclipse 是个还不错的选择。 固然你也能够选择 IntelliJ IDEA。 但是对开发同1项目的团队来讲，大家1定要选择同1套。
对各种IDE工具来讲，优点应当是各有千秋，选择1个最合适项目，合适团队的。这个工作可以在项目进入开发阶段时大家1起挑选。
3. 统1的开发环境
开发人员常见的开发方式 1种是在本地建立个人开发环境进行开发， 另外1种是在1台共用的服务器上建立个人开发环境进行开发， 使用代码控管工具(P4 or Git)进行代码的获得或提交。
不论是哪一种，常常会有以下状态产生：
1) 新加入member请老员工查看本地开发遇到的问题
2) AP 1 请AP 2 在AP 1 上查看AP 2 写的Code 的问题
3) 大家1起在某台机器上会诊某个问题
如果每一个开发人员的开发环境相差甚异，必将会浪费1些没必要要的熟习环境的时间。 所以， 统1大家的开发环境的路径，开发项目名称，统1的部署测试脚本也就不无裨益了。
4. 统1的编码规范
衍生统1的开发环境， 团队成员使用统1的代码规范， 像代码文件路径，文件命名， 类的命名， 方法命令，变量命令，参数命令都能统1的话， 彼此之间熟习代码就会比较快，保护和更改也就方便了。
1般项目的设计与开发中， 必不可少的总有共用模组的存在。(如果没有，就要反思1下了)。
共用方法， 共用类， 共用模块。 总有1些部份是可以提取出来供团队来使用的。除方便其他人，加快开发速度。
相对每一个人都写1套类似的东西，花比较少的时间来提炼，锤炼共用的功能部份，使共用的部份无毛病，高效力，对提示项目的质量也大有好处。
但是，共用组件的提取和宣扬是需要有专门的意识和计划的， 相对单个开发人员来讲， 完成了既定功能的开发，是时间要求很紧的状态下，他个人是没有精力也不想花额外的时间去做共用化的，更别说宣扬和推行了。
固然， 即便共用的组件也不能从共用后就不再变化了， 功能完善与升级也是需要相应的途径的。
简言之， 以生命周期的方式来管控和保护共用组件。 从计划，到实行，到销售，到更新升级，到Release .... .
1个团队要做正确的事，要正确的做事， 在统1"语言"以后，是很有计划达成 1+1 >2 的效果。 但是1定要确保正确的做事，同理之，如果某个成员制造了1个Bug, 影响的不但是他自己， 毛病一样也会出现 1+1>2 的状态。
所以，每一个人代码质量都要尽可能有保证。
自动代码Check, 定期的Code Reviewer, 结对编程都不失为1种好的做法， 一样，选择合适团队的状态的方法就能够了。