从不同的视角来看有哪些最佳实践呢？
- 提交代码修改的人
| 阶段 | 最佳实践 |
|---|---|
| 准备需要review的修改 | 1.彻底地看过自己要提交的更改，确保是需要review的内容 |
| 2.每次更改都是小的递增的修改，且应当是紧密相关的，以便易于理解，不要一次提交大量代码变动 | |
| 3.应当附带说明信息，说明每处修改的动机，描述改动了什么 | |
| 4.在发起review前先测试改动，提交测试的相关信息 | |
| 5.使用自动化代码分析工具，检查代码格式风格，处理一些低级的问题 | |
| 6.一些很小的，不重要的改动，可以跳过review。比如一些不涉及程序逻辑变动的修改，比如注释、格式等 | |
| 选择帮忙做review的人 | 1.决定需要多少个人帮忙review |
| 2.选择合适的有经验的人来review，不一定要最有经验的人，应当权衡他们的时间 | |
| 3.允许别人自愿参加review | |
| 4.通知那些参加review可以获益的人，比如新人，他们可以从中学习 | |
| 对review做出响应 | 1.对帮忙review的人表示感激 |
| 2.使用有效的手段去沟通，邮件/即时通讯/电话/面对面沟通，取决于修改的复杂度 | |
| 3.对review的结果进行跟踪，确保bug修复，建议得到跟进 |
- review 代码的人
| 阶段 | 最佳实践 |
|---|---|
| 处理一个review | 1.为review预留足够的时间，确保理解修改了什么东西 |
| 2.经常性review，每次review 少量改动 | |
| 3.尽快地进行反馈，以便大家还对这个改动有记忆 | |
| 4.关注核心的问题，不要一直纠结在一些小问题上面 | |
| 5.用一个checklist列出你关注的问题，甚至可以为这个项目定义一些特定的关注事项 | |
| 提供反馈意见 | 1. 选择合适的沟通手段，取决于你要说的问题多复杂 |
| 2. 一些没有很大争议，不太敏感的内容，可以直接利用review工具提供的评论功能进行反馈，以便于追踪讨论历史 | |
| 3.给出有建设性的意见，同时也要尊重他人 | |
| 4.解释清楚你拒绝本次变动的原因 |
- 组织的角度
| 最佳实践 |
|---|
| 1.建立一种积极的review 文化，让大家直到review是是一种互惠的活动 |
| 2.在项目里，确保review的时间也被预计在内，因为他也是软件生命周期重要的部分 |
| 3.关注review中消极的部分，认真做review应当称赞，也有人把review当做走流程，视为儿戏 |
| 4.确保有效的自动化工具，使得review 顺利进行 |
| 5.不断回顾和迭代review策略，关注它对开发效率，产品质量，开发者的满意度的影响 |
| 6.关注review中一些不合适的言辞、争论的 |
| 7.要有合适的培训，确保大家的review高效 |
参考：《MS-Code-Review-Tech-Report-MSR-TR-2016-27》
