大家的公司的 Code Review 都是怎么做的？遇到过哪些问题？

阿凡达提问于 2018-08-14 12:41

• 把生命浪费在美好事物上2018-08-14 12:48

  怎么做Code Review？有什么具体的操作方法与措施？

  笔者建议因地制宜，所谓在什么山头唱什么山歌。怎么做Code Review依赖具体团队实际情况及意愿。

  • 准备工作。
  • 确认是否已经做好了思想准备。思想意识是否已统一，或者就算不统一，是否有强权人物介入（万不得已最好不要这样）。
  • 确认是否预留了余闲时间。若不给更多时间就要求在原有工作基础上做更多改变尝试，就有点流氓了。
  • 方法和工具准备。搜罗和尝试适合当下团队的。仅简单罗列一些搜罗来的工具。CodeFlow、gerrit、crucible、reviewboard、Eclipse 的Metrics 插件、 Eclipse 的PMD 插件CPD功能（复制粘贴探测器，用于寻找重复代码）、JDepend（检查包依赖关系）、Checkstyle插件、Software Analyzer等。如果团队同时在用jira和git，那么把它俩联通吧。当git中有push操作时调用jira接口，发出请求，对任意位置包含例如 ’ #JIRA- 1001’标记的commit内容解析同步到对应jira任务的备注中 。建议考虑尝试代码提交的命令中自动提醒和强制code review，能靠法制的，就不要人治。
  • 人工介入前先通过工具的review。利用好工具。包括是否统一标准命名、代码格式规范等。最基本的，总应该做下静态代码分析吧。

  
  

  • Review开始。
  • 明确review的范围、需求等，介绍，包括设计思想、数据结构、程序代码结构等，若存疑当场提出。 陈序明建议敏捷实践中把设计合理性也纳入review范围，有些项目，在转敏捷开发后，提高了开发效率，设计的质量却下降了。作为团队中一员的工程师也有义务协助去背锅（心疼工程师们），重构也好或者想其他办法也好，但因为开发水平不一，有必要加强Code Review。
  • 是否准备review的清单，不建议做强制要求。
  • 形式，建议面对面沟通review，不建议只是把代码交给某人看下等结论就完事儿了。可以尝试增量式review。有必要的话，当面沟通后检查人员可再单独进一步核查，最终需给出反馈结论和建议。参与review的人员一起检查反馈结果，讨论商议改进方法，做出改进尝试。
  • 知识经验沉淀存档，如在confluence中存档相关经验总结、文献资料及各种知识库等。

  
  

  • 来自腾讯的案例。【引用开始，以下摘自《让 Code Review成为一种习惯》】如何建设一个团队的 code review 文化， 跟随 Google 的脚步， 也有一些具体的意见：
  • 需要培养合格的reviewer。 建立各种编程语言的readability认证机制，从一组“种子”reviewer开始，让更多同事获得认证成为合格的reviewers。
  • 需要细化和公开各种语言的code style。 评注中可以给出建议的出处的URL，使得保持代码风格和可维护性落到实处。
  • 需要建立Code Lab机制。 帮助工程师们入门开发流程和规范。
  • 需要建立change approval机制。 鼓励组内更多工程师改进代码（敏捷），但是修改在提交前除了必须通过review，还需要相关责任人的approval；在加速开发滚动的同时，保证权责分明。
  • 引导轻量 review。我们都经历过有些工程师发一个 change issue 的时候， 几十个文件一并发出来， 一个 issue 可能是累积一周的修改， reviewer 看到这种 issue 几乎都是崩溃的，不可能保证 review 质量。 所以好的 issue 应该是轻量的， 大的 issue 应该拆分为小的 issue 发送。下图是 Cisco 公司的codereview 报告中摘出的， 如果一个 issue 的修改代码行数超过 400， 基本上 reviewer 是不可能认真 review 帮你找出 bug 的。

  • 明确issue 能否提交是工程师自己的责任。开发人员有时候抱怨别人 review 得慢， 拖延时间。 我们小组内部通常明确指出：一个 issue 能否提交是开发人员自己的责任。 开发人员自己要积极推动合作人员帮忙 review issue， 推动 issue 被通过并及时提交。【引用结束，向原作者火光摇曳致敬！】

  
  

  以上答案来自我厂吕广川老师的博文《玩转敏捷系列之「玩转Code Review」》。