Code Review： 超越“审、查、评”的代码回顾

http://news.cnblogs.com/n/532148/

 

　文/TWInsights-伍斌 

　　Code Review 应该是软件开发团队“共同学习、识别模式和每日持续”的过程，而不是带有“审、查、评”等令人感到紧张气氛的过程。

　　Code Review 的目的，是团队成员聚在一起共同学习，而不是相互“挑错”。在相互挑错的场合里，人的内心会本能地封闭起来，来抗拒那些针对自己的批评意见。相互挑错所造成的紧张气氛，会让程序员对 Code Review 望而却步，从而情绪低落，这会让 Code Review 的效果大打折扣。而人们常用的“代码评审”或“代码走查”这些 Code Review 的称谓中所出现的“审、查、评”等字眼，会诱发“挑错”的气氛，所以我觉得还是把 Code Review 称为“代码回顾”好一些。如果大家放弃“挑错”，来“共同学习”，那么在代码回顾里要学习什么呢？

　　代码回顾的学习重点，是团队成员共同识别模式。这里的模式指的是程序员编写代码的习惯，包括“好模式”和“反模式”。像富有表达力的类名、单一职责的方法、良好的格式缩进等等，都是“好模式”。而像那些令人迷惑的缩写、几百行的一个类文件、负责的 if-else 嵌套等等，都是“反模式”。团队成员通过阅读最近编写的测试代码和生产代码，来一起识别“好模式”和“反模式”，既是团队成员之间相互学习的过程，也是团队整体达成编写整洁代码共识的过程。

　　既然代码回顾的学习重点是识别代码编写的好模式和反模式，那么代码的作者就不是重点。在代码回顾的过程中，完全可以不提谁是代码的作者，而只提“好模式”和“反模式”，这样能让作者放松心态，更好地接受合理的建议。

　　既然代码回顾的学习重点是识别代码编写的好模式和反模式，那么在代码回顾中发现的 bug 也不是代码回顾活动的重点。老虎也有打盹儿的时候，谁不犯错儿呢？好模式和反模式，其实就是编程的好习惯和坏习惯。代码回顾应该重在识别编程习惯，而不是找 bug。

　　另外需要注意的是，一些高手在代码回顾时，即使代码本身已经符合整洁代码的要求，他们也会不自觉地提出自己的不同写法，甚至会提出另一种全新的设计。高手们提出这些看法，虽然很有价值，但都不是代码回顾所关注的。高手们可以在代码回顾会后，私下再找作者沟通，这样能令代码回顾会议更专注和高效。

　　代码回顾的形式，应该是每日持续进行的。因为只有这样，才能持续改进团队的代码编写水平。要想能让代码回顾每日持续下去，一方面要像上面讲的那样，不“审、查、评”，不针对作者去找 bug，来去除“挑错”的紧张气氛，营造“识别模式”来“共同学习”的环境，吸引团队成员长期参与；另一方面，也需要将每日代码回顾的时间控制在半小时以内。因为代码回顾的重点是识别模式，而模式就是习惯，习惯在很少的代码中就能体现出来。看过一些代码并识别出一些好习惯和坏习惯后，即使再看更多的代码，也不会识别出更多种类的习惯。基于这一点，每日的代码回顾仅需要在半小时内大家一起看 200～300 行随机抽取的当天编写的代码就够了。

　　下面是我在客户现场实践上述“代码回顾”的具体做法：

1. 团队7～8 位程序员，下班前半小时聚在会议室里，在一位主持人的引导下做代码回顾；
2. 主持人问：“咱们今天回顾哪段新写的代码？”一位志愿者在投影仪上调出今天编写的一段代码的新旧对比图；
3. 主持人说：“我们知道，如果代码编写得好，那么不是作者的人就能在没有作者帮助的情况下读懂。我希望一位不是这段代码作者的志愿者，来为大家解释一下这段代码是做什么的。”一位非作者的志愿者上来逐行解释代码，并回答大家的疑问。
4. 主持人等代码解释完后，问大家：“这段代码大家还有看不懂的地方吗？”如果有问题，包括作者在内的参会者都可以回答问题，但大家都不提谁是作者。
5. 大家都看懂代码后，主持人问：“大家说说这段代码有没有好的编写模式咱们可以继续发扬？”最初几次代码回顾，好的模式很少。但是即使这样，也一定要找出一些好模式，比如“缩进很好”，“花括号的位置放得很好”，诸如此类。以后几次代码回顾，要尽量找那些被改正过来的曾经的反模式，比如“这段代码用到了方法提取，且命名富有表达力，改掉了昨天’长方法’的反模式”。只识别反模式，不识别好模式，会让代码回顾退化到令人生畏的代码审查，打掉大家长期坚持的积极性。
6. 提完了好模式，主持人问：“大家说说这段代码有没有可以改进的反模式？”大家开始提反模式，注意不要提谁是作者。
7. 主持人在整个过程中注意计时，快到半小时的时候，可以这样结束代码回顾：“今天时间也快到了，代码回顾的重点在识别模式，而不是看全部的代码。希望大家继续发扬今天识别到的好模式，另外在明天代码回顾时，把今天识别到的反模式改进为好模式。”

　　把 Code Review 称作“代码回顾”吧，而不要称作令人紧张的“代码评审”或“代码走查”，把它打造成软件开发团队“共同学习、识别模式和每日持续”的过程，来有效提升团队代码内在质量。

　　注：本文参考了 Shawn Wildermuth 在 Pluralsight.com 上的培训视频 Lessons from Real World .NET Code Reviews

　　内容来源：ThoughtWorks 洞见