无论多么牛B的人，都不能开发出完全没有问题的软件。
引入代码评审是不错的主意。
代码评审并不能保证我们的代码不出问题，而是用来在软件发布前尽可能多地找到并解决问题。它引入一个或多个同事同时阅读我们的代码，能够更容易地找到更多问题，而且在软件发布之前修复问题的成本是极低的。
代码评审有如下好处：
- 更少的bug数。开发人员可能还在持续地产生bug，不过代码评审将会减少最终发布软件的bug总量。
- 更好的安全性。代码评审能够比较容易地定位潜在的代码缺陷，能够在发布之前修复。
- 共享知识。团队成员能够在评审对方的代码时学到有用的知识，知道哪些应该坚持，哪些应该摒弃。
- 控制代码质量。比如可读性、效率、可维护性，这些指标对长期维护的项目极其重要。
- 获得更好的性能。代码评审能够发现性能问题。
代码评审主要步骤：
- 开发人员使用分支实现特性和bug修复的开发工作
- 分支开发就绪后，开发人员请求代码评审
- 团队的其他成员评审分支上的代码
- 编制评审时发现的需要修改的条目
- 开发人员针对这些条目修改代码并提交
- 再次评审，直到该分支被批准发布
- 该分支被合并到其它分支，进行测试或发布
第一步：写代码、请求评审。
- 创建分支，在其上进行开发
- 每一个特性和bug修复都要创建分支
- 分支能够提高开发效率，减少干扰和冲突。
- 不通的特性使用不同的分支并行开发
- 分支开发完成后，在进行测试之前进行代码评审
- 此时修复代码的问题所花费的成本最低
- 主持评审的人一般是团队里经验丰富的成员
- 有时候会让对某模块不是很熟悉的人主持此模块的代码评审，由于与此人熟悉此模块的业务和代码逻辑
如何进行代码评审的准备工作，以便让评审主持人有足够的信息引导评审进程？
- 确保自己开发的代码具备自表达（self-explanatory）能力，有能满足阅读代码需要的文档和注释
- 提供自动化的测试用例，便于验证代码能够正常工作
- 如果被评审的分支是修复bug用的，要包括bug重现的步骤说明和验证bug修复的详细数据
- 请求代码评审时，请用简短明了的描述说明分支实现的目标
第二步：评审代码、反馈结果。
- 提出问题，讨论
- 有必要更改的形成记录，开发工具支持的话可以直接创建任务
评审代码时的主意事项：
- 每次评审不要超过400行代码，时间控制在90分钟内
- 较大的分支可以分成多次进行评审
- 对需要重点检查的内容事先形成检查列表，用于所有的评审，评审时针对这些项逐一检查。这个检查表在整个团队内共享。可以包括：
- 代码的文档和注释是否合适
- 是否遵守公司的代码规范
- 测试用例是否覆盖了特性的功能
- 是否有代码重复的情况
- 其他...
- 确保特性和bug修复能够正常工作
- 评审时产生的问题，使用简洁明了的、易实行的注释或问题条目记录，避免大段难读、难理解的文字描述
第三步：修复发现的条目，结束评审。
没什么好说的，提出问题的人查看问题是否得的修复，最终大家同意参与评审的分支进入下一步，评审完成。
注意：本文归作者所有，未经作者允许，不得转载
