代码是程序员的一切,让我们快乐,让我们忧愁。看着优雅的代码,赏心悦目,看到恶心的代码,痛苦不堪。那么,是什么让代码变得恶心呢?
网上有如下解释:架构不合理,需求变更,进度压力…… 首先,我觉得任何架构都是合理的,也都是不合理的。一个基本架构,能够完成现有的功能,效率上也说得过去,那么,它就是一个合理的架构。任何一个架构,都会不断的经受需求变更的挑战,没有任何人可以一开始就设计出完美的架构。所以流传着很广的一句话:好的架构,是改出来的。其次,需求变更时必然的,如果没有需求变更,就是要求设计师一开始就设计出完美的产品,就等于一开始就要求你设计出完美的架构,你做得到吗?最后,进度压力面前,就有理由让你写垃圾代码?时间一紧,领导一催,你就慌得向兔子?
从我自己的经历来理解,人员变动和项目管理才是代码变烂的两大主要原因。君不见,一个经历一年的项目,第一批程序员完成第一期,第二批程序员完成第二期……,其实第二批程序员都还没有完全把控第一期的代码。第一批程序员的很多设计想法,第二批程序员都不知道,然后第二批程序员就按照自己的方式,开始在代码中搞东搞西。最后就出现了做同样一件事情,项目中出现N种解决方式(刚毕业的大学生进入这种项目组就爽了,做一个项目,收获多个项目的项目经验)…… 项目管理:为了完成一个功能,很多团队的做法是:那个谁谁谁,你可以完成吗?谁谁谁说:可以。然后就开始搞,搞好了,测试随便点几下,做了一个简单的用户测试,ok,这个功能就完成了,试问,这样怎么保证代码质量呢?
***********************************************************************************************************************************************
下面附录一篇相关的文章,分析的比我好,写的也比我好:
很多团队都有这个问题,一个项目的代码本来开始设计得好好的,一段时间以后,代码就会变得难以理解,难以维护,难以修改。为什么?我一直在思考这个问题。
让我们先看一个人的情况。
1.程序员的成长
新手的代码
新手的代码没有经验,基本不考虑代码设计,代码规模稍稍大一点则自己就乱了。
进阶者的代码
小规模的时候
大规模的时候
进阶者已经知道如何设计代码,懂得代码规则,但一般局限于一个模块。规模一大,模块间的调用就会比较混乱,难以维护。
有经验者的代码
有经验者的代码,模块内部代码整洁,模块之间层次清晰,有设计模式,有成熟的体系。可以保持长期的代码整洁。
那么一个团队里面会出现什么情况呢?似乎,我们只要让一堆有经验的人来开发,那么代码必然不会出什么问题。可惜,事实不是这样。
2.背景
代码风格的多样性
有这样的。
也有这样的
放眼一看,会发现不同的代码风格,不同的设计思想,不同的设计理念。每个程序员都有自己的代码个性。
团队层次的差异
一个团队内部有新人,有熟手,有牛人。一个设计好的架构可能会变坏。
3.原因
风格的融合
当程序员A和程序员B在一起的时候,会有如下变化
原本整洁的代码变得不整洁了。
进度的压力
进度导致了“飞线”的产生,未经设计的代码在时间的借口下产生了。
多个人修改一个模块
4.本质
所有代码腐烂问题的本质是沟通问题。其表现又都可以统一为修改别人的代码。
当一个程序员在没有沟通的情况下,修改另一个程序员的模块的代码的时候,他可能不理解此模块的设计思路,代码结构,逻辑结构,于是按自己的想法去修改,虽然看起来解决了眼前的问题。但是留下了一个不稳定因素。此因素可以通过重构来解决。但是,大家都非常的“忙”,谁也没有空时间去Review代码,去沟通我改了你的哪里的代码。所以不稳定的因素越来越多,导致了代码的腐烂。
最快腐烂的代码,一定是很多人在修改的代码,相反,长期由一个人来维护的代码,就不会那么容易腐烂。因为一个人不存在沟通的问题,他修改代码的时候,明确的知道自己应该怎样去修改,怎样让代码更整洁。
5.解决
就一个办法,多沟通。
当你工作的时候需要修改别人的代码的时候,应该先找这个人沟通。说清楚需要改动的逻辑,然后尽量让他来修改。这样可以保证一块代码是由一个人维护,这样成本最少。
如果此人真的太忙,没有时间,那么你必须说明你的计划,让他做一个建议,最好能让他给你讲讲此模块的设计思路,代码设计,逻辑设计,现在的问题,以后的计划。保证你修改的代码都是合理的。
最理想的状态就是整个团队的思想是高度统一的,N个人可以像一个人那样去工作。这个需要团队长期的磨合。
你可以会想到,我们制定一个规范不就可以了么?纸面上的规范通常是不起作用的,成功团队的规范是在整个团队达到一个很高的水平以后总结的经验。与其说执行规范,不如说是学习经验。MFC的代码像是由一个人写出来的,Office所有产品都像是一个人做出来的。这就是高度的统一。我们把微软的规范搬过来,不一定就有效果。
代码的腐烂都是由于没有深入理解的情况下修改别人的代码导致的。
总结一下:
- 解决的方法就是任何修改之前确保经过深入的沟通。
- 简单的规则是一个模块仅允许一个人维护。
- 理想的状态是整个团队思想高度统一。