Code Review 的巅峰

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。