文/TWInsights-伍斌
Code Review 应该是软件开发团队“共同学习、识别模式和每日持续”的过程,而不是带有“审、查、评”等令人感到紧张气氛的过程。
Code Review 的目的,是团队成员聚在一起共同学习,而不是相互“挑错”。在相互挑错的场合里,人的内心会本能地封闭起来,来抗拒那些针对自己的批评意见。相互挑错所造成的紧张气氛,会让程序员对 Code Review 望而却步,从而情绪低落,这会让 Code Review 的效果大打折扣。而人们常用的“代码评审”或“代码走查”这些 Code Review 的称谓中所出现的“审、查、评”等字眼,会诱发“挑错”的气氛,所以我觉得还是把 Code Review 称为“代码回顾”好一些。如果大家放弃“挑错”,来“共同学习”,那么在代码回顾里要学习什么呢?
代码回顾的学习重点,是团队成员共同识别模式。这里的模式指的是程序员编写代码的习惯,包括“好模式”和“反模式”。像富有表达力的类名、单一职责的方法、良好的格式缩进等等,都是“好模式”。而像那些令人迷惑的缩写、几百行的一个类文件、负责的 if-else 嵌套等等,都是“反模式”。团队成员通过阅读最近编写的测试代码和生产代码,来一起识别“好模式”和“反模式”,既是团队成员之间相互学习的过程,也是团队整体达成编写整洁代码共识的过程。
既然代码回顾的学习重点是识别代码编写的好模式和反模式,那么代码的作者就不是重点。在代码回顾的过程中,完全可以不提谁是代码的作者,而只提“好模式”和“反模式”,这样能让作者放松心态,更好地接受合理的建议。
既然代码回顾的学习重点是识别代码编写的好模式和反模式,那么在代码回顾中发现的 bug 也不是代码回顾活动的重点。老虎也有打盹儿的时候,谁不犯错儿呢?好模式和反模式,其实就是编程的好习惯和坏习惯。代码回顾应该重在识别编程习惯,而不是找 bug。
另外需要注意的是,一些高手在代码回顾时,即使代码本身已经符合整洁代码的要求,他们也会不自觉地提出自己的不同写法,甚至会提出另一种全新的设计。高手们提出这些看法,虽然很有价值,但都不是代码回顾所关注的。高手们可以在代码回顾会后,私下再找作者沟通,这样能令代码回顾会议更专注和高效。
代码回顾的形式,应该是每日持续进行的。因为只有这样,才能持续改进团队的代码编写水平。要想能让代码回顾每日持续下去,一方面要像上面讲的那样,不“审、查、评”,不针对作者去找 bug,来去除“挑错”的紧张气氛,营造“识别模式”来“共同学习”的环境,吸引团队成员长期参与;另一方面,也需要将每日代码回顾的时间控制在半小时以内。因为代码回顾的重点是识别模式,而模式就是习惯,习惯在很少的代码中就能体现出来。看过一些代码并识别出一些好习惯和坏习惯后,即使再看更多的代码,也不会识别出更多种类的习惯。基于这一点,每日的代码回顾仅需要在半小时内大家一起看 200~300 行随机抽取的当天编写的代码就够了。
下面是我在客户现场实践上述“代码回顾”的具体做法:
把 Code Review 称作“代码回顾”吧,而不要称作令人紧张的“代码评审”或“代码走查”,把它打造成软件开发团队“共同学习、识别模式和每日持续”的过程,来有效提升团队代码内在质量。
注:本文参考了 Shawn Wildermuth 在 Pluralsight.com 上的培训视频 Lessons from Real World .NET Code Reviews
内容来源:ThoughtWorks 洞见