代码评审鲜为人知的好处

代码评审究竟有什么好处？

在前期发现问题，提高软件质量，降低软件成本。

事实上，代码评审的好处远不止这些。有些项目经理或者开发人员不愿意多提评审，Coding的过程包含的内容非常丰富，如果只把一个字符一个字符地敲代码叫做Coding，未免悲哀了一点。优秀的项目，编码阶段实际敲代码的时间不会很长；优秀的程序员，大部分时间都用来思考了。

 

我来说说代码评审其它鲜为人知的好处，兴许能改变某些同学的看法呢。

 

增加阅历，学习别人代码的可贵之处

和英语学习是一个道理，如果只听一种纯正口音的英语，英文反而不容易学好，我们需要阅读各种营养的代码，广泛阅读能帮助开阔眼界，积累一些好的设计思路，甚至提高阅读恶心代码的免疫能力。

 

对工程和业务逻辑的熟悉

和盲目地走读代码不同，代码评审之前起码是对大致的业务和实现有一定了解，是带着问题去看代码的，更容易帮助自己理清代码实现，熟悉业务逻辑。

 

大声地鼓励，宽容地讨论，知识共享，给团队一个互相学习进步的氛围

代码评审不是挑错，看到优秀的代码，要说出来，让大家都看得到，这是那些优秀代码的创造者们应得的奖励。团队中的其他人听到了表扬，阅读了代码，从身边最实际的例子当中收获了成长。

评审过程中，提出的问题未必最终被接受，但是在问题确认的辩驳、争论过程中，很容易见到思维的火花，所谓“道理越辩越明”，一个团队需要有这样充满生气的讨论。

 

及时识别出代码设计的缺陷，找到需要重构的地方

有一种观点很可怕：写最终的产品代码才是王道，不把最终的代码敲出来，程序员不放心，项目经理不放心，老大们更不放心——“你们的产出率是多少行/天啊？”

软件的精华应当在设计，如果说做软件是一种充满创造性的劳动，那么思考能力正是真正将优秀的软件开发和简单的体力劳动所区分开的核心因素。遗憾的是具备相当思考特质的程序员越来越不好找了，一定程度上，敏捷和TDD甚至助长了这种轻视前期设计阶段的情形（敏捷和TDD本身是没有问题的，问题终归来自实践的“人”）；“先写呗，开发的过程中，如果发现明显不合理的地方，再重构呗！”，在很多情况下，重构、尤其是一定规模下的重构很可能会成为噩梦。

代码评审不能完全解决这个问题，但可以通过评审发现设计方面的问题，可以反思设计的疏漏，提高团队成员的设计能力。

 

找出安全、性能、依赖和兼容性等测试不易发现的问题

把问题的寻找全部依赖于测试是可怕的，同等发布质量的前提下，测试发现问题的比重越小，修改的成本也就越小。在很多公司，都没有单个版本的专职测试（但可能有专职负责若干个产品集成的测试人员），但这不意味着版本质量差，事实上，很可能每一个开发人员都可以是一个优秀的测试人员；而更可能的情况是，Story转测试之后软件接近商用，发现的问题并不多。等到上线，代码有多个人阅读，他们对check in的代码共同保证质量、承担责任，远好过出了问题对某一个人的追查。

 

评审新员工的代码，给新员工引导一个实实在在的方向

犯过的错误容易记忆，具体的问题容易记忆，对于新员工来说，给他们代码中肯的评价，可以帮助他们上路。比如我们常说不要过度设计，可是怎么样才算过度设计，如果给新员工指出他代码中这样一个实际的问题，他一定不容易忘记。

 

发挥团队中“牛人”的作用

这些团队中的“牛人”可不见得写得了所有的代码，但是他们可以评审绝大多数代码，把他们的作用发挥出来。他们未必要去审查每一条上库的语句，但是他们需要保证上库代码的质量，评审，给项目的质量带来事半功倍的提升。

 

PS：这篇文章里面，还提到了几种牛叉的评审风格。

 

 

文章系本人原创，转载请注明出处和作者