Code Review

张大胖工作快一年了，这一年看了不少书，尤其是编程实践方面，例如单元测试、重构、持续集成等等， 和公司的开发现状一对比， 就发现很多软件开发实践不够规范，比如说Code Review完全就没有。

张大胖是那种遇到问题不逃避，不推脱，反而迎难而上的人，他心想既然现在公司没有这个流程，我可以提议，甚至推动把Code Review这件事情给建立起来。

他在中午吃饭时“勾搭”了一下部门经理，把想法汇报了一下，成功取得了经理的支持和授权：推动Code Review流程的建立。

张大胖先收集了很多资料发给大家，用于宣传Code Review的好处 ， 他制作了一个精美的PPT，召集会议给大家预热讲解。

随后他便结合公司的源码管理工具， 建立了强制Code Review的制度，没有经过Code Review的代码，不允许进入代码库。 至少有两个人Review过代码才算通过。

CheckStyle 和连坐

张大胖满心期待这样的流程能够发现Bug ，提高代码质量，可是试运行了一周以后，静悄悄的，大家通过Code Review纠结的尽是一些代码风格的问题：缩进不够了，空格太少，一行的字符太多了等等， 这对于提高代码质量并没有很大的帮助，还浪费了不少时间。

张大胖思考了一阵，决定引入工具来自动化地做这些琐碎的事情，比如Checkstyle，用工具把这些代码风格问题消灭在程序员的本地代码中， 不改正Checkstyle发现的问题，连代码评审这一步都走不到。

这下子大家必须得动动脑子去Review代码了吧！张大胖想。

但人都是懒惰的，想改变习惯是很难的。 又过了一周，那几个资深的骨干说：哎呀，太忙了，自己的代码还写不完，怎么可能Review别人的代码？

Code Review的效果自然也好不到哪里去。 这时候一直在观察的部门经理对张大胖做出了强有力的支持，他宣布了一项制度：连坐。 即代码的质量由写代码的人和Review代码的人共同负责。

Check List

张大胖心想这个制度肯定会伤害一些人，但是也应该会调到大家的积极性，将来等到大家习惯养成了，就可以废除这个连坐了。

果不其然，Review代码发现的有效问题开始增多。只是大家的喜好不同，关注的重点不同，老李关注可读性，老王习惯看各种异常处理和次要分支条件，老方喜欢看类的设计是否合理， 大周最关心代码对别的模块的影响，还有性能问题......

张大胖是个有心人，他把这些问题总结，分析了一下，形成了一份Code Review Check List，列举出来Code Review应该关注的点， 请各位资深大牛审查，补充以后便正式颁布实施。

大家都挺认可这份CheckList， 积极性也提高了，张大胖想，这下可以消停一阵了。

代码量控制

没想到新问题很快就出现了，有些人不喜欢“小步快跑”，总是在工作了一周以后，达到阶段性目标以后才愿意提交代码Review， 这就带来了两个问题： 一个是Reviewer 一下子面对大量的代码，看不过来，很容易丧失信心，于是草草扫过了事。 第二个是如果发现了严重问题，再让作者返工，也是很难的。

张大胖赶紧和大家商量，不要一下子提交这么多代码，而是要小步快跑，控制每次Review代码的数量。 大家同意每次Review的代码要控制在200至400行以内。 让Reviewer有意愿去做真正的Review，而不是流于形式。

另外对于特别复杂、特别重要的模块，要专门把相关人等“纠集”到一起，在会议室中一行一行做严格的代码评审。

经过这么一番折腾，大家终于养成了习惯，原来的“连坐”机制也废除了，改成了奖励机制，给与那些在代码评审中发现重要Bug的人以精神和物质的奖励。

张大胖发现，其实Code Review改变了人的思想意识，原来为了快速完成功能，大家写代码的时候都没有思考太多，现在不一样了，一想到自己的代码马上就要被别人审视， 就像开源软件一样，写得小心翼翼了。还会对照着CheckList好好想想，尽自己最大努力写好代码，看起来在开发上花费的时间唱了，但是Bug大量减少了。慢慢地，自己的水平也提高了。

结对编程： Code Review的巅峰

一天晚上上网浏览时，张大胖发现了一个有趣的东西：极限编程。

这个极限编程是敏捷软件开发领域的一个“奇葩”， 它的宗旨就是：如果一个软件开发的实践很好，我们就把它做到极致！

所以既然测试是好的，我们就先写测试，再写代码 ，这就是TDD。

既然Code Review这么好，那我们就在一个程序员写代码的时候，安排另外一个人时时刻刻去Review代码，定期让这两个人的角色互换， 这就是结对编程。

看到这里，张大胖激动地一下子跳了起来： 卧草，这才是Code Review的巅峰啊！

第二天上午，张大胖兴冲冲去找经理，希望在部门实施结对编程， 可这一次经理并没有像上次那样全力支持，只是答应他小范围尝试。

张大胖找了和自己水平差不多的小李和自己结对编程，尝试共同完成一个需求。张大胖一会儿当Driver， 主要控制键盘写代码；一会儿当Navigator，关注宏观目标，思考问题，并且Review。

一天时间下来，他俩的共同感受就是：真TMD累！

小李开玩笑地说：“下次你给我安排个女生一起‘结对编程’吧， 男女搭配，干活不累！”

原来“单干”的时候遇到问题了，总是想休息一下，拿起手机看看新闻，刷刷朋友圈，时间很快就过去了。虽说一天工作9个多小时，但是真正高效率的编程时间可能还不到4个小时。  现在可好，旁边一直有个人盯着，精神时刻处于高度紧张之中，不是在写代码，就是在思考怎么解决问题。

写出代码质量确实不错，Code Review时以及测试阶段几乎没有发现问题。

向经理汇报时，张大胖做了如下的总结：

1. 心态得开放，愿意“暴露”自己，并且接受别人的建议

对很多程序员来讲，并不愿意暴露自己编程的思路和技术水平，这也算是程序员的小隐私了。结对编程就得要求思维的透明化，别人得充分了解你的思路，从而能了解你的水平。 尤其是自己写每一行代码都被人盯着，随时接受“审判” ， 如果没有开发的心态，是做不到的。

2. 当Driver在写代码时，不能频繁地被打断。

张大胖有几次在专心致志地写一个复杂的功能时，小李老是提示他变量名命名不合适，其实他自己也知道，只是还没改，这让他很不爽。

3. 不能太霸道

小李有一段时间一直霸占着键盘不放，自己说了好几次他才恋恋不舍地把键盘递过来。

4. 两个人的水平应该差不太多。

如果差得太多，就变成了一个人教另外一个人编程了。

经理听了以后说道：“结对编程看起来很美，执行起来还是有难度的，很多人不愿意在写代码的时候被别人盯着，不愿意'暴露'自己。它的见效周期也比较长，管理层不愿意看到两个人干一份活儿， 我们还是先放下吧。”

虽然心有不甘，但是张大胖承认经理说得很对，暂时放弃吧。

年终的时候，张大胖由于对Code Review这个制度的建设而获得了公司的奖励，他总结了一些成功的经验：

1. 领导的支持

2. 民主的决策

3. 能用工具完成的，就别让人再麻烦了。

4. CheckList很有用

5. 每次review适量的代码

【本文为51CTO专栏作者“刘欣”的原创稿件，转载请通过作者微信公众号coderising获取授权】

戳这里，看该作者更多好文