协同开发

同一个开发项目中如果有多名程序猿，那么每个程序猿都有责任培养自己协同开发的意识，为的是代码的质量，质量，质量（重要的事情说三遍！！！）。
协同开发是个挖坑和填坑的过程，自己做的好可以尽量避免自己挖坑，还可以帮队友填坑，但最重要的是可以少点给队友挖坑。这里最苦逼的会是，队友无意识的往自己写过的代码里边挖坑。。。
提高协同开发能力和代码质量，我提几点建议（欢迎拍砖）：

新尝试前的交流

开发人员技术水平参差不齐，势必在开发效率和质量上会差很多，这体现在面对同一个问题，不同经验和技术水平的猿会有不同的解决思路。当然这些解决方法都归于技术，技术差的猿自然相对会捉襟见肘。技术优劣与思路优劣在整体上看是正比的，但并非一概而论，对于每一个具体的问题，两者的相关性是有波动的，也意味着最高技术水平的猿不一定能想出最优的解决思路。
这里我说的“新尝试前的交流”，不是开发前的交流，因为不是所有的开发前都需要交流，那样成本大，效率低，面对相似的问题用原有的方式并遵循原有的规范去开发即可，不需要交流。而对于“新尝试”，指的是在面对同样的问题时想要用不一样的实现方式，或者是在针对性地去优化代码。
为什么要在这时候交流？所谓新的实现方式，它是要经过多方面审核和考验的：

• 是否考虑全面，覆盖了原先实现方式解决的问题范围？

• 是否更优，如何比原先的实现方式好？内存消耗少？工程量小？扩展性强？覆盖面更广？更易于理解？

• 是否最优，比其他猿的方法好？

• 。。。。。。

既然至少有我这里提到的几点理由，那么除非自我感觉这些点都满足了才可以跨过交流直接开发，否则还是有必要去做的。
当然，这也需要考虑一些特殊情况：

• 项目人猿少，比如前端就一个，后端就一个，那互相交流各自领域如何解决某个问题的必要性就不是很强。

• 牛猿，技术面广，有丰富的经验，基本比其他猿考虑得更加全面，那交流的必要也不是很强。

• 项目紧急，任务繁重，时间成本大，耗不起这个时间，可以先开发，后期再交流。

• 。。。。。。

新尝试前的交流，在技术水平相差不多的猿之间，必要性较强，收益也不低。原因在于：毕竟同个项目，代码借鉴度高，相互引用的几率高，并且想要针对的问题有可能是另一只猿原先解决过的。这种交流可以有挺多好处：

• 可以查缺补漏，新尝试的方式对于原先考虑不全的地方可以提前发现，提前解决。

• 可以对比提升，其他猿有意无意的话中可能会带来灵感，这种灵感碰撞在交流中很常见，可以让这种新尝试迅速“迭代”成熟。

• 可以提高自信，如若这种新尝试得到他猿的认同和肯定，那无疑是对自己的最大支持，开发起来也会更加有信心。

新尝试前的交流，在技术水平相差有些距离的猿之间，对于比较差的猿来说，会有较大收益：

• 一字值千金，牛猿的几句话可以让这种新尝试直接升华，促进技术的提升和方案的更加完备。

• 一字千金重，牛猿的几句话可以瞬间将这种新尝试扼杀在摇篮里，甚至突破心理防线，直至崩溃。

代码完工后的Code review

还记得给其他猿挖了多少坑吗？还记得给多少用户埋了多少地雷吗？更惨的是，还记得踩过多少自己挖的坑吗？甚至是多次踩中同一个坑。
Code review的必要性不言而喻，但还是要言一下：

• Code review可以帮助检查代码风格。代码风格是另一个很大的话题，具体到特定的团队中，至少要做到代码符合规范。在其他猿的帮助校准下，可以促进更好地养成良好的代码习惯，也提高了工程代码的一致性和可读性，不会说同一个工程中代码风格千姿百态，引用了某一块代码之后还得再重新调整成符合自己的风格，那这样子是非常糟糕和难看的。

• Code review能提高代码质量。这体现在多个方面。一是通过其他猿帮助优化代码。是否实现方式太拖沓冗余？是否重新实现了原来就有的方法而没有去直接引用？是否实现得太复杂而且还没有注释？二是能及早发现问题。是否不小心对其他代码开了刀没有缝上？这可是给队友挖坑埋地雷啊，可以容忍？或者是否考虑不周全，忽略了某个方面？

• 工程一开始总是建立在考虑很周全的框架上的，前期很丰满，可以很高效得进行后期开发，尤其是针对差不多的功能。工程慢慢大了，在中途停下来重新审视代码，对代码进行整体优化，提高整体性能，这也是Code review的一部分。不过，如果在每一次的代码完成之后都能执行一次Code review，那么后期在重新审视代码的时候，就不会发现：每只猿都需要去研究其他猿的代码质量，也不会惊讶居然某些代码块重复了，某些代码块质量不行，某些代码块风格不行。而是能够一心针对整体去做优化，更容易达成一致，也更容易一并去执行优化。

• 我觉得单独给Code review设定一个岗位都是可以的。

当然，这样的建议很需要斟酌和针对场景，权衡时间成本和最终效益，是个难题。