微软如何做好Code Review

从不同的视角来看有哪些最佳实践呢？

1. 提交代码修改的人

阶段	最佳实践
准备需要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修复，建议得到跟进

2. review 代码的人

阶段	最佳实践
处理一个review	1.为review预留足够的时间，确保理解修改了什么东西
	2.经常性review，每次review 少量改动
	3.尽快地进行反馈，以便大家还对这个改动有记忆
	4.关注核心的问题，不要一直纠结在一些小问题上面
	5.用一个checklist列出你关注的问题，甚至可以为这个项目定义一些特定的关注事项
提供反馈意见	1. 选择合适的沟通手段，取决于你要说的问题多复杂
	2. 一些没有很大争议，不太敏感的内容，可以直接利用review工具提供的评论功能进行反馈，以便于追踪讨论历史
	3.给出有建设性的意见，同时也要尊重他人
	4.解释清楚你拒绝本次变动的原因

3. 组织的角度

最佳实践
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》