代码评审流程（摘要）

原文：Code review workflow

无论多么牛B的人，都不能开发出完全没有问题的软件。

引入代码评审是不错的主意。

代码评审并不能保证我们的代码不出问题，而是用来在软件发布前尽可能多地找到并解决问题。它引入一个或多个同事同时阅读我们的代码，能够更容易地找到更多问题，而且在软件发布之前修复问题的成本是极低的。

代码评审有如下好处：

• 更少的bug数。开发人员可能还在持续地产生bug，不过代码评审将会减少最终发布软件的bug总量。
• 更好的安全性。代码评审能够比较容易地定位潜在的代码缺陷，能够在发布之前修复。
• 共享知识。团队成员能够在评审对方的代码时学到有用的知识，知道哪些应该坚持，哪些应该摒弃。
• 控制代码质量。比如可读性、效率、可维护性，这些指标对长期维护的项目极其重要。
• 获得更好的性能。代码评审能够发现性能问题。

代码评审主要步骤：

• 开发人员使用分支实现特性和bug修复的开发工作
• 分支开发就绪后，开发人员请求代码评审
• 团队的其他成员评审分支上的代码
• 编制评审时发现的需要修改的条目
• 开发人员针对这些条目修改代码并提交
• 再次评审，直到该分支被批准发布
• 该分支被合并到其它分支，进行测试或发布

第一步：写代码、请求评审。

• 创建分支，在其上进行开发
• 每一个特性和bug修复都要创建分支
• 分支能够提高开发效率，减少干扰和冲突。
• 不通的特性使用不同的分支并行开发
• 分支开发完成后，在进行测试之前进行代码评审
• 此时修复代码的问题所花费的成本最低
• 主持评审的人一般是团队里经验丰富的成员
• 有时候会让对某模块不是很熟悉的人主持此模块的代码评审，由于与此人熟悉此模块的业务和代码逻辑

如何进行代码评审的准备工作，以便让评审主持人有足够的信息引导评审进程？

• 确保自己开发的代码具备自表达（self-explanatory）能力，有能满足阅读代码需要的文档和注释
• 提供自动化的测试用例，便于验证代码能够正常工作
• 如果被评审的分支是修复bug用的，要包括bug重现的步骤说明和验证bug修复的详细数据
• 请求代码评审时，请用简短明了的描述说明分支实现的目标

第二步：评审代码、反馈结果。

• 提出问题，讨论
• 有必要更改的形成记录，开发工具支持的话可以直接创建任务

评审代码时的主意事项：

• 每次评审不要超过400行代码，时间控制在90分钟内
• 较大的分支可以分成多次进行评审
• 对需要重点检查的内容事先形成检查列表，用于所有的评审，评审时针对这些项逐一检查。这个检查表在整个团队内共享。可以包括：
• 代码的文档和注释是否合适
• 是否遵守公司的代码规范
• 测试用例是否覆盖了特性的功能
• 是否有代码重复的情况
• 其他…
• 确保特性和bug修复能够正常工作
• 评审时产生的问题，使用简洁明了的、易实行的注释或问题条目记录，避免大段难读、难理解的文字描述

第三步：修复发现的条目，结束评审。

没什么好说的，提出问题的人查看问题是否得的修复，最终大家同意参与评审的分支进入下一步，评审完成。