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

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

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

 文/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 洞见

上一篇:java程序中实现打开 某个指定浏览器


下一篇:mssqlservers数据嗅探