玩转敏捷系列之「玩转Code Review」

敏捷宣言中有一条价值观是“工作的软件高于详尽的文档- Working software over comprehensive documentation”。Code Review是实现工作软件的一大利器。所谓，“物有本末，事有终始，知所先后，则近道矣”。接下来笔者将讲一讲敏捷中Code Review相关的本末始终，探究一下门道在哪儿，让我们一起玩转Code Review。

首先，Why？

为什么要Code Review？有什么目的、理念？除了类似减少缺陷等现实需要以外还有哪些更深层次更利于持久坚持下去的原因？或者是如下图，这就是程序员为什么要做 Code Review 的原因？

 

言归正传，接下来从哲学、管理学和企业文化三个角度来探讨下为何要做Code Review。

哲学。利他和利己，借鉴自稻盛和夫哲学。稻盛和夫说：“利他本来就是经商的原点。”对照到工作中，利他本来就是团队合作的原点。关于利己，笔者认为利己是最原始冲动，可以带来积极改变但不够持久，如果有利他保驾护航，就完美了。Code Review毋庸置疑对自己是有好处的，你坚持了，总可以有一些类似避免后面返工折腾等的受益。你坚持了，对他人也是有好处的，集体配合更顺畅，更融洽。最终还是会反馈到对个人有好处，你坚持的好，你会逐渐被认可，例如当你获得一句“这是一个靠谱的人”的评价时，你心已暖。心怀利他和利己，下次辩论（撕逼）的时候，也可以放下面子放下架子，辩（撕）的更坦荡更真诚一些。

管理学。现代管理学之父彼得·德鲁克认为知识工作者是重要的资源，也是最重要的投资。高度发达的工业社会，经济上最迫切需要的，莫过于提高知识工作者的生产力。玩转Code Review ，就是在提高产品技术人员的生产力，使得同样的时间内生产更多可用可交付的代码。

企业文化。工程师们合力打造良好的交流氛围，有气质，有修养，有技术信仰，敢于挑战，精益进取。最重要，给新人一个良好的土壤，薪火相传。笔者曾写过一篇文章，关于项目经理的骑士精神。其实，工程师才是真正的一线骑士，工程师文化是企业文化的重要组成部分，而工程师文化里，Code Review应占有一席之地。传统大团队统一开会统一培训知识经验更容易集中传播。敏捷方法多种，以Scrum为例，它是有天然劣势的，多个小团队之间很容易彼此不知道彼此有哪些更好的经验及知识，多个小团队会重复浪费学习成本等。Code Review是一个学习和分享的过程，利用这种机制，让知识和经验更好的流动碰撞，团队成长，最终企业受益。

其次，How？

怎么做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 被通过并及时提交。【引用结束，向原作者火光摇曳致敬！】

最后，What？

有什么现象和成果？

Code Review可以提高代码可读性，发现缺陷，发现代码中技术逻辑（如数据库连接打开是否忘记关闭，是否正确使用线程，Exception 处理，密码是否加密存储等）错误。让系统及产品更稳健可靠。存档记录。避免只有一个人对某部分代码了解，多人共享，解决所有鸡蛋放在一个篮子的隐患。帮助新人更快成长，促进产出更规范的代码，提高注释的质量，保持代码的维护可持续性。团队成员应该参与享受这个互助、沟通、协作的过程，不断学习。

  

综上所述，从Why、How及What三方面探讨了在敏捷实践中如何玩转Code Review。如果你觉得Code Review没用且太教条，如果你觉得业务逼的太紧了没时间，如果你觉得主要矛盾就是倒排出来的工期和不靠谱的程序员之间的矛盾，凡此种种，但如果你还想做技术还想做的更好，更体面，那么你可以考虑看下《从Code Review 谈如何做技术》这篇文章，作者陈皓（左耳朵耗子）。

如果准备为Code Review实践提供一些奖励的话，笔者建议，奖励当面并且及时，最好是惊喜。不是很推荐事先明确奖励条件的奖励。因为这样奖励时，容易把握不好时机和程度，容易变成贿赂，最后反而让大家对奖励形成依赖，久而久之没有奖励时大家任何事情都不愿意去做，注意力放在如何赢得奖励上，忘记了本该做什么。正如开篇所提“物有本末，事有终始，知所先后，则近道矣”。

一旦下定决心要玩转Code Review，那么就请拿出勇气来行动吧！塞万提斯说过：失去财富是损失，失去朋友同样是损失，而失去勇气则是最大的损失。

与君共勉！

 

*彩蛋*---“黄金圈法则”

本文来自网易实践者社区，经作者吕广川授权发布。