如何防止代码腐烂

sea_bug

　　作者：Stack Huang

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

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

1.程序员的成长

新手的代码



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



　　小规模的时候



　　大规模的时候

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

有经验者的代码



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

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

2.背景

代码风格的多样性

　　有这样的。



　　也有这样的



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



团队层次的差异



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

3.原因

风格的融合

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



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

进度的压力



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

多个人修改一个模块



4.本质

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

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

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

5.解决

　　就一个办法，多沟通。

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

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

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

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

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

　　总结一下：

　　　　解决的方法就是任何修改之前确保经过深入的沟通。

　　　　简单的规则是一个模块仅允许一个人维护。

　　　　理想的状态是整个团队思想高度统一。

来自：腾讯

gantleman

混乱这种东西也没有客观标准，
微软的秘密里给出一个答案，
找到聪明，有技术，有管理能力的人。
理想的状态时团队高度平衡，
技术，产品，市场，管理都没有短板，
各自都明白其他队员的能力，
不做超出整个团队能力范围之外的事情，
代码混乱是平衡被打破的现象。
最长见的现象是前期以做出产品为重，
技术团队受到重视，所有资源向技术偏斜。
做出来的东西功能考虑不全，产品定位不准。
中期像产品倾斜硬塞功能进去，导致代码快速膨胀，
开发方向开始飘摇，技术团队半失控。
后期向市场倾斜，开始做一些根本做不出来的功能，
或者勉强作出的功能被快速遗弃。
导致技术团队代码开始极度混乱无法维护。
如果公司还没倒闭那么开始新的产品
新的产品又不能借鉴上次的教训，循环又重新来过。
现在有种更恶劣的趋势就是开始就是产品导向。
微软的秘密透露，微软的产品经理每个项目组只有一个。
现在的恶劣趋势是每个程序员有个产品经理。
不说其他恶劣的后果，
单单多个产品经理产生的产品开发风格不一致就够恶心的。

DeALLBugs

典型的提出了问题，没有解决方案。
看到前面写的无比正确，满怀期待的有个解决方案，看到沟通两个字的时候直接崩溃了。。。。。
就说人员流动的问题，离职了你怎么沟通。。。
中国的软件行业缺乏的就是构架设计师，也许某些大公司有吧，大多数的公司都觉得只有写代码才是程序人员的工作。。。

getfile

没有什么终极解决方案, 关键的就是核心人物要稳定

cn_zhangJW

说实话，写的非常之好，看来腾讯还是有不少人才。

cn_zhangJW

解决的办法就是模块化，单个模块尽量由个人负责。只要把握住模块间低偶尔，模块内高内聚，由理解深刻的人把关，细化到每个模块，模块就可以由个人实现了。如果架构天生支持，那么这个问题解决起来就更方便了。—— 顺带卖一下瓜，本人正好就有这样一套被应用于跨STB和PC的开发套件，欲寻求合作伙伴。

无名剑

cn_zhangJW: Re:如何防止代码腐烂

解决的办法就是模块化，单个模块尽量由个人负责。只要把握住模块间低偶尔，模块内高内聚，由理解深刻的人把...

理论没啥问题,实施成本太高了!! 最后还是回归到最简单做法算了
把代码实现目标弄清 把代码要做的事情弄清晰
然后再开始把代码拼好就行了
至于啥模式啥架构,有时候堆了一大票 反而除了把简单问题复杂化之外无其他作为