如何防止代码腐烂
1.程序员的成长
新手的代码
新手的代码没有经验,基本不考虑代码设计,代码规模稍稍大一点则自己就乱了。
进阶者的代码
小规模的时候
大规模的时候
进阶者已经知道如何设计代码,懂得代码规则,但一般局限于一个模块。规模一大,模块间的调用就会比较混乱,难以维护。
有经验者的代码
有经验者的代码,模块内部代码整洁,模块之间层次清晰,有设计模式,有成熟的体系。可以保持长期的代码整洁。
那么一个团队里面会出现什么情况呢?似乎,我们只要让一堆有经验的人来开发,那么代码必然不会出什么问题。可惜,事实不是这样。
2.背景
代码风格的多样性
有这样的。
也有这样的
放眼一看,会发现不同的代码风格,不同的设计思想,不同的设计理念。每个程序员都有自己的代码个性。
团队层次的差异
一个团队内部有新人,有熟手,有牛人。一个设计好的架构可能会变坏。
3.原因
风格的融合
当程序员A和程序员B在一起的时候,会有如下变化
原本整洁的代码变得不整洁了。
进度的压力
进度导致了“飞线”的产生,未经设计的代码在时间的借口下产生了。
多个人修改一个模块
4.本质
所有代码腐烂问题的本质是沟通问题。其表现又都可以统一为修改别人的代码。
当一个程序员在没有沟通的情况下,修改另一个程序员的模块的代码的时候,他可能不理解此模块的设计思路,代码结构,逻辑结构,于是按自己的想法去修改,虽然看起来解决了眼前的问题。但是留下了一个不稳定因素。此因素可以通过重构来解决。但是,大家都非常的“忙”,谁也没有空时间去 Review 代码,去沟通我改了你的哪里的代码。所以不稳定的因素越来越多,导致了代码的腐烂。
最快腐烂的代码,一定是很多人在修改的代码,相反,长期由一个人来维护的代码,就不会那么容易腐烂。因为一个人不存在沟通的问题,他修改代码的时候,明确的知道自己应该怎样去修改,怎样让代码更整洁。
5.解决
就一个办法,多沟通。
当你工作的时候需要修改别人的代码的时候,应该先找这个人沟通。说清楚需要改动的逻辑,然后尽量让他来修改。这样可以保证一块代码是由一个人维护,这样成本最少。
如果此人真的太忙,没有时间,那么你必须说明你的计划,让他做一个建议,最好能让他给你讲讲此模块的设计思路,代码设计,逻辑设计,现在的问题,以后的计划。保证你修改的代码都是合理的。
最理想的状态就是整个团队的思想是高度统一的,N个人可以像一个人那样去工作。这个需要团队长期的磨合。
你可以会想到,我们制定一个规范不就可以了么?纸面上的规范通常是不起作用的,成功团队的规范是在整个团队达到一个很高的水平以后总结的经验。与其说执行规范,不如说是学习经验。MFC的代码像是由一个人写出来的,Office所有产品都像是一个人做出来的。这就是高度的统一。我们把微软的规范搬过来,不一定就有效果。
代码的腐烂都是由于没有深入理解的情况下修改别人的代码导致的。
总结一下:
- 解决的方法就是任何修改之前确保经过深入的沟通。
- 简单的规则是一个模块仅允许一个人维护。
- 理想的状态是整个团队思想高度统一。