作者:Stack Huang

 

  很多团队都有这个问题,一个项目的代码本来开始设计得好好的,一段时间以后,代码就会变得难以理解,难以维护,难以修改。为什么?我一直在思考这个问题。

  让我们先看一个人的情况。

1.程序员的成长

新手的代码

  

  新手的代码没有经验,基本不考虑代码设计,代码规模稍稍大一点则自己就乱了。


进阶者的代码

     小规模的时候

大规模的时候

  进阶者已经知道如何设计代码,懂得代码规则,但一般局限于一个模块。规模一大,模块间的调用就会比较混乱,难以维护。


有经验者的代码


  有经验者的代码,模块内部代码整洁,模块之间层次清晰,有设计模式,有成熟的体系。可以保持长期的代码整洁。

  那么一个团队里面会出现什么情况呢?似乎,我们只要让一堆有经验的人来开发,那么代码必然不会出什么问题。可惜,事实不是这样。

2.背景


代码风格的多样性

  有这样的。

  也有这样的

  放眼一看,会发现不同的代码风格,不同的设计思想,不同的设计理念。每个程序员都有自己的代码个性。


团队层次的差异

  一个团队内部有新人,有熟手,有牛人。一个设计好的架构可能会变坏。

3.原因


风格的融合

  当程序员A和程序员B在一起的时候,会有如下变化

  原本整洁的代码变得不整洁了。


进度的压力

  进度导致了“飞线”的产生,未经设计的代码在时间的借口下产生了。


多个人修改一个模块


 


4.本质

  所有代码腐烂问题的本质是沟通问题。其表现又都可以统一为修改别人的代码。

  当一个程序员在没有沟通的情况下,修改另一个程序员的模块的代码的时候,他可能不理解此模块的设计思路,代码结构,逻辑结构,于是按自己的想法去修改,虽然看起来解决了眼前的问题。但是留下了一个不稳定因素。此因素可以通过重构来解决。但是,大家都非常的“忙”,谁也没有空时间去Review代码,去沟通我改了你的哪里的代码。所以不稳定的因素越来越多,导致了代码的腐烂。

  最快腐烂的代码,一定是很多人在修改的代码,相反,长期由一个人来维护的代码,就不会那么容易腐烂。因为一个人不存在沟通的问题,他修改代码的时候,明确的知道自己应该怎样去修改,怎样让代码更整洁。

 

5.解决

  就一个办法,多沟通。

  当你工作的时候需要修改别人的代码的时候,应该先找这个人沟通。说清楚需要改动的逻辑,然后尽量让他来修改。这样可以保证一块代码是由一个人维护,这样成本最少。

  如果此人真的太忙,没有时间,那么你必须说明你的计划,让他做一个建议,最好能让他给你讲讲此模块的设计思路,代码设计,逻辑设计,现在的问题,以后的计划。保证你修改的代码都是合理的。

  最理想的状态就是整个团队的思想是高度统一的,N个人可以像一个人那样去工作。这个需要团队长期的磨合。

  你可以会想到,我们制定一个规范不就可以了么?纸面上的规范通常是不起作用的,成功团队的规范是在整个团队达到一个很高的水平以后总结的经验。与其说执行规范,不如说是学习经验。MFC的代码像是由一个人写出来的,Office所有产品都像是一个人做出来的。这就是高度的统一。我们把微软的规范搬过来,不一定就有效果。

  代码的腐烂都是由于没有深入理解的情况下修改别人的代码导致的。

  总结一下:

  • 解决的方法就是任何修改之前确保经过深入的沟通。
  • 简单的规则是一个模块仅允许一个人维护。
  • 理想的状态是整个团队思想高度统一。