如何防止代码腐烂

发布时间:2011-11-14

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

我们先看一个人的情况。

1.程序员的成长

新手的代码

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

如何防止代码腐烂

进阶者的代码

如何防止代码腐烂

小规模的时候

如何防止代码腐烂

大规模的时候

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

有经验者的代码

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

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

2.背景

代码风格的多样性

有这样的。

 

如何防止代码腐烂

也有这样的

如何防止代码腐烂

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

如何防止代码腐烂

团队层次的差异

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

如何防止代码腐烂

3.原因

风格的融合

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

如何防止代码腐烂

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

进度的压力

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

多个人修改一个模块

如何防止代码腐烂

4.本质

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

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

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

5.解决

就一个办法,多沟通。

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

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

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

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

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

总结一下:

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

文章出自:djt.open