客户端敏捷开发之道【二】：代码质量篇
发表于2016-11-28
正式参加工作已逾三年，打算把工作沉淀下来的方法论整理出来，以作纪念。思来想去，还是觉得用「敏捷之道」贯穿这个系列最为合适。由于每年新沉淀的方法论，是在以往的经验基础上总结的，因此本系列文章具有一定的前后依赖关系，建议按顺序阅读。
对于很多程序员来说，代码质量并不是最关心的东西，甚至有的开发团队还会出现抵触提高代码质量的氛围，这是怎么回事呢？代码质量真的如他们说的那样无足轻重吗？如果您也对此感兴趣，那么本文值得一读。
（一）终极问题：Clean Code有用吗？
周末，当你走进一家KTV唱歌的时候。你是更看重这家KTV装潢的是否漂亮，歌曲是不是完整，服务是不是周到，还是看这家KTV墙壁是否结实耐用，是否达到抗震级别？
同样，当你使用一款互联网产品的时候，你是看这个产品的功能是否易用、满足你的需求，还是看代码设计是否合理，是否易读，框架是否混乱？
这个问题是国内某互联网大佬在一次聚餐上谈笑风生时提到的，这个问题正面挑战代码质量的价值。 第一次听到这个问题时，我陷入深思，并且无法回答这个问题，我怀疑过自己是不是该尝试转职做产品经理。因为毕竟产品经理做得才是“装潢、歌曲完整、服务周到”的工作。关于开发和产品经理的话题，也许会在后续文章中提及。
（二）当梦想照进现实，你还能推动代码整洁吗？
程序员：老大，我们X模块代码太烂了，我想找个时间重构一下代码，可以不？
Leader：可以呀，那你说一下重构之后能带来哪些好处吧！
程序员：可以让代码质量更高，运行更稳定！
Leader：噢，那有没有数据证明呢，你预期重构之后，哪些数据能提高？提高到多少？
程序员：好像不太好证明。
Leader：噢，我看看，现在X模块各项指标都是达标的，而且这个模块的bug也都已经清理了，那进行重构会不会引入新的bug呢？
程序员：好像会，理论上是会引入bug的，重构后要重新测试。
Leader：噢，那听起来这次重构会引入bug，还要消耗人力测试，并且没法带来明确的好处，那我看就算了吧。
如果遇到这种情况，你会怎么办？
（三）代码质量首先是程序员的利益，而非公司利益
试想这样一个场景，你是一个送货员，你被分配到去山的另一端送货。此时摆在面前的有汽车，摩托车，有自行车。我们的雇主并不关心我们使用什么交通工具送货，雇主只关心货物是否安全送达，以及你是否能安全送达。此时，如果我们的代码一团糟，到处都是随意启动的线程。模块耦合极大，那么也许5分钟本来可以查出的bug，在这种代码下要查一下午。这和自行车送货与汽车送货是不是很相似？
每个程序员的精力都是有限的，当你花大量的时间在蹬三轮，那么我们将疲于蹬三轮，蹬三轮登到海枯石烂。但是如果我们花5分钟的时间开车把货送到，我们则有足够的精力思考，这里是不是可以修个路。那里是不是可以架个桥，这趟送货到底有什么意义，大头利润被老板赚了，我能否也从货源地上货，直接卖出去。这时，程序员才可能摆脱每天蹬三轮的噩梦。
所以说，代码质量是程序员摆脱无尽噩梦的第一步。
（四）事实上，代码质量也间接是公司的利益
扩散性百万亚瑟王停运内幕：核心成员离职，程序员接手不能
作为一个有代码洁癖的开发者，你接手那些思维凌乱的代码结构和哭笑不得的命名方式时是怎样的心情？【链接已失效】
简单来说，烂代码会导致破窗效应，加剧代码变烂，积累技术债务，最终降低团队效率。烂代码会加剧程序员离职意向，导致团队凝聚力松散，这些都不容易直接体现在数据中。
（五）什么才是好代码？
其实对于本文来说，这部分已经不重要了，因为在许多团队中，能让每个程序员认清代码质量的价值，已经跨越了最大的鸿沟。
对于好代码的定义可以有很多：
1、可供程序员炫技的代码（如在C++写非常复杂的宏，大段大段的插入汇编）
2、性能好的（为了追求性能的少许提高，大规模的复杂逻辑）
3、bug少的
4、使用了全新组件的
但是，一般来说：易读的代码才是好代码。
正如上一篇所提到，代码是一个动态变化的过程。即使性能不够好，由于代码易读，易于修改，查找问题和优化可以是非常方便的。但是如果虽然代码性能很高，但是没人看得懂，一旦出现变更，将非常麻烦。有时，程序员为了炫技会写很多难以理解的东东，这早晚会应了那句话「不是不报，时候未到」。
关于代码质量的标准、重构的方法等等在许多书中都有介绍，因此这里不花篇幅做赘述。可以阅读相关书籍，学习代码质量的相关技能，例如：《代码整洁之道》《重构》《修改代码的艺术》。
另外值得一提的是，改正代码编写习惯是一个从刻意到自然的过程。一般来说，代码质量较高的程序员，都会有一段时期刻意的纠正自己编码习惯。亦或是公司要求，亦或是CR严格执行，但这对整个职业发展都有很多好处。
（六）遇到烂代码，何时重构才是最好的
由于抛出了问题（二），这里不得不接住这个问题。
事实上「如何写好代码」和「如何修改烂代码」是两个话题，介绍前者更多的是《代码整洁之道》这类书。介绍后者更多的，比如《重构》《修改代码的艺术》。问题（二）的情况，是典型的「如何修改烂代码」的问题。一般来说，推荐的方法是：先控制住，再逐步修复的路径。不宜拿出大头时间来做重构，对项目安排和收益预期都有较大不可控风险。
相关阅读
客户端敏捷开发之道【一】：设计模式篇