代码审查（Code Review）的一些最佳实践
Contents
在我之前的文章SmartbBear给出的11条代码审查最佳实践里聊了一些关于Code Review的建议，最近又看了很多这方面的文章，把其中一些最佳实践记录如下。本文的内容主要来源于下面这几篇文章。
- Code Review Guidelines for Humans
- 30 Proven Code Review Best Practices from Microsoft
- Google Engineering Practices Documentation
针对代码提交者的
- 保持开放、学习的心态。
- 相信所有人的代码都有改进的空间。
- 自己不是完美的。
- 接受自己会犯错误。
- 无论自己多优秀，还是有学习和进步的空间
- 不要把自己的专业性和可靠性等同于绝对正确和完美无瑕。
- 你不等同于你的代码
- 写程序是一项技能，是一项可以通过学习不断改进而且永无止境的技能。
- 不要把你的自我价值等同于你写的代码。
- 理解代码审查者和你自己的最终目标是一致的：创建高质量的代码。你们是一伙的。
- 想想宜家效应（消费者对于自己投入劳动、情感而创造的物品的价值产生高估的价值判断偏差现象）。你可能会过于看重你自己写的代码。
- 把反馈看作对你代码从另一个角度的解读，并且理解这个新的角度的价值。
- 能帮你找到对你来说太自然从而没有显式的从代码里表达出来的知识。
- 避免你自己的一些片面视野。
- 代码审查是讨论，不是命令。你可以不同意审查者的意见，当然你需要解释给审查者从而达成共识。
- 提交之前仔细检查代码变动。
- 尽量提交小的代码改动。通常“10行代码我会找到10个问题，500行代码我会说看上去不错”。
- 代码改动应该是高内聚的，并且只做了一件事。
- 提供针对代码改动的描述。代码审查者通常不会像你一样对改动的上下文非常清楚。
- 提交代码前保证测试（手动或者自动）可以通过。
- 尽量利用自动化工具来保证改动符合代码规范。这样审查者可以把精力放在逻辑上。
- 对没有必要的代码跳过代码审查。比如自动生成的代码、利用靠谱的重构工具自动重构的代码。
- 挑选合适的代码审查者，并明确对他们的期待。
- 对代码审查者提供反馈表示尊敬和感谢。
针对代码审查者的
- 使用“我认为……”的句式。
- 好的意见：“我不太能理解这段代码”。
- 差的意见：“你写的代码很难懂”。
- 讨论代码，而不是代码提交者。
- 好的意见：“这段代码发起了多次调用，效率不高”。
- 差的意见：“你发起了多次调用，效率不高”。
- 尽量问问题，而不是做结论。
- 好的意见：“你觉得这样改怎么样？”。
- 差的意见：“你得这么改”。
- 评价行为，永远不要评价代码提交者的特征。
- 好的意见：“我建议多写一些测试”。
- 差的意见：“你总是偷懒不写测试”。
- 理解并且接受会有不同的解决方案。
- 好的意见：“我会用另一种方法来解决这个问题，不过你的解决方法也没问题”。
- 差的意见：“我总是用另一种方法来解决这个问题，你也应该一样”。
- 区分通用的最佳实践和个人偏好。
- 务实，在适当的时候做出妥协。
- 不要对每行代码、每个小问题都提意见，这通常会惹怒代码提交者，并不利于接受你的意见。关注主要问题，不要吹毛求疵。
- 充分尊重代码提交者。
- 没有人会故意写不好的代码。
- 代码提交者已经在能力范围内尽力了。
- 在给意见的时候考虑“观察-影响-请求”的方法。
- 观察：“这个方法有100行”。
- 影响：“对我来说理解这个方法有点困难”。
- 请求：“我建议抽几个小的方法，并给它们一些显而易见的名字”。
- 在给意见之前，问问自己：
- 这个意见是对的吗？还是只是自己的看法或者偏好。
- 这个意见是有必要的吗？避免挑刺或者超出范围的工作。
- 这个意见是友好的吗？不要有侮辱性的意见。
- 谦虚，自己也有可以改进的地方。
- 看到亮眼的地方不好吝啬自己的赞美。
- 给出建设性的反馈。
- 权衡你要直接给出修改建议，还是指出问题让代码提交者决定怎么解决。
- 有不清楚的地方时鼓励代码提交者把解释放在代码里，而不是只跟审查者讲明白了。
- 如果需要的话可以面对面的沟通。
- 把代码审查的结果记录下来。
- 解释你的观点。
- 不要经常直接拒绝代码。
- 把代码审查作为每天日常工作的一部分。
- 最好有特定的代码审查时间，避免经常上下文切换从而降低自己的效率。
- 及时做代码审查。
- 如果是分布式团队，考虑跨时区的问题。
- 让整个团队都理解代码审查的价值，都积极参与进来。
- 可以先从测试代码开始审查。
- 使用代码审查清单（Code Review Checklist）。你应该构建符合你的项目的代码审查清单，比如：示例1, 示例2。
