任何软件都是协同开发的，所以 CodeReview 非常重要，它可以帮助你减少代码质量问题，提高开发效率，提升稳定性，同时还能保证软件架构的稳定性，防止代码结构被恶意破坏导致难以维护。
所以 CodeReview 机制是否健全是一个工程团队能否长期健康发展的决定因素之一，这次我们读一篇关于 CodeReview 如何做得更好的文章： how-to-make-good-code-reviews-better。
作者结合自己在 Uber、微软的工作经历介绍了自己对如何做好 CodeReview 的看法。
Good CodeReview 会检查代码的正确性、测试覆盖率、功能变化、是否遵循代码规范与最佳实践、可以指出一些较为明显的改进点，比如难以阅读的写法、未使用到变量、一些边界问题、commit 数量过大需要拆分等等。
Better CodeReview 会检查引入代码的必要性，与已有系统是否适配，是否具有可维护性，从抽象角度思考代码是否与已有系统逻辑能够自洽。
Better CodeReview 会关注在可维护性层面，并具有全局性，往往几个局部正确的代码组合在一起会产生错误的结果，或者是没必要的代码，或者是相互冲突的逻辑。Better CodeReview 更多用在底层架构场景，因为架构底层模块关联比较紧密，需要有整体视角，而业务上层模块间最好采用解耦模式，这样不仅不需要更耗费精力的 Better CodeReview，也是一种更正确的架构设计。
Good CodeReview 会给出建设性意见，而不是发表强硬措辞要求对方改正，或认为自己的意见是唯一正确的答案，因为这样的评论其实具有一定攻击性，激发对方的防御心理，产生敌对心态，这样会从内部瓦解一个团队。最好能给出建议，或者多个选择，给对方留有余地。
Better CodeReview 永远是考虑全面且正向积极的，会对写的好的地方进行鼓励，对写的不好的地方也体现出善解人意的关怀，考虑到对方可能花费了很多心血，以一种换位思考的鼓励心态进行评论。
其实读到语气这一章节，逐渐发现 CodeReview 不仅是一个技术专业行为，还是一个人与人相处的社交行为，有的人平时与人打交道非常谦逊，但在 CodeReview 中就变得尖酸刻薄，显然是只关注到了 CodeReview 的专业性这一面，忽略了社交性这一点。而要做到 Better CodeReview 还要学会换位思考，体现出包容、正向积极的态度，因为你技术经验更丰富，能指出别人的问题很正常，但能保持谦逊，让别人容易接受并受到鼓励，可以让你成为一个有气度的技术专家。
Good CodeReview 不会轻易通过那些开放式 PR，至少在其被得到充分讨论前，但每个 Review 者对自己关注的部分完成 Review 后需要进行反馈，无论是 “看起来不错” 或者用缩写单词 “LGTM”，之后需要有明确的跟进，比如通过协作软件通知作者进行进一步反馈。
Better CodeReview 实际执行中会更加灵活一些，对于一些比较紧急的改动会留下改进建议，但快速通过，让作者通过后续代码提交解决遗留的问题。
实际工作场景会遇到一些开放式或紧急的提交，良好的 CodeReview 习惯自然是要严谨一些，讨论清楚再通过，并且要及时反馈。但某些比较紧急的提交就要区别对待了，更好的态度是在实践中灵活对待，但及时紧急通过了，也要保证问题在后续得以修复，比如在代码中留一些 "TODO" 或 "FIXME" 的标记，写上对应的负责人与预期解决时间。
Good CodeReview 会给出完整的评论和修改建议，如果后续提交的代码不符合预期，Review 者可以直接与代码提交者面对面交流，这样可以避免后续花费更多沟通时间。
Better CodeReview 会在第一次给出完整的评论和修改建议，如果后续提交代码不符合预期，会立即与代码提交者当面沟通，避免异步沟通带来更多的理解偏差。
补充一下，在 PR 内容过多时也可以选择直接与提交者当面沟通，这样可以更多理解作者的想法，使 Review 准确性更高。另外并不要每次都直接交流，异步的 CodeReview 本身就是一种提效方案，这会使你工作节奏把握在自己手中，仅在这种方案出现沟通问题时再选择当面交流。
Good CodeReview 可以区分提示的重要程度，并在不太重要的改动前面加上 “nit:” 标记，这样可以使提交者的注意力集中在重要的问题上。
Better CodeReview 会采取工具手段解决这些问题，比如一些代码 lint 工具，因为这些问题往往是可以被工具自动化解决的。
代码自动化工具的目的，很大一部分也是为了保证代码一致性，从而降低 CodeReview 成本，也减少不重要的评论信息出现，让 CodeReview 尽可能反馈逻辑问题而不是格式问题。
Good CodeReview 对任何人都是用相同评判标准，可以遵循上面几点注意事项。
Better CodeReview 会对新人区分对待，对新人给予对多的耐心、解释和评论，甚至给出解决方法，并更积极的给出鼓励。
任何人到一家新公司都有适应过程，一视同仁是 base 要求，但如果能给予新人更多关怀就更好啦。
Good CodeReview 仅在工作时间有重叠的时间范围内进行 CodeReview，这样能保证对方可以积极响应，在必要时进行语音、视频沟通。
Better CodeReview 会注意到更本质的问题，留意跨团队协作的必要性，如果某个模块经常被另一个时区同时修改，也许可以将这个模块交给对方维护，或者将 CodeReview 交给对方团队内部进行会更加高效。
笔者所在公司也有跨时区协作情况，但绝大部分场景会避免跨时区的 CodeReview，因为 CodeReview 一般会在同一时区团队内部进行，这样效率更高，应对跨时区协作时，往往也是电话、视频会议优先。
Good CodeReview 会得到公司组织支持，公司能意识到这么做虽然看起来占用开发时间，但长远来看提升了开发效率，因此能任何 CodeReview 价值。
Better CodeReview 会得到公司进一步支持，公司甚至不断研发并完善 CodeReview 系统与流程，通过系统化方案保证上面几项 CodeReview 注意事项是否有在团队内落实，可以全员参与。
CodeReview 也是一种团队文化和公司文化，公司文化带来的是规章制度与系统工具，团队文化带来的是良好 CodeReview 氛围与更高 CodeReview 的效率。
总结一下，良好的 CodeReview 需要做到以下几点：
- 更全面，从正确性到系统影响评估。
- 注意语气，从给出建设性一觉到换位思考。
- 及时完成审阅，从充分讨论到随机应变。
- 加强交流，从面对面交流到灵活选择最高效的沟通方式。
- 区分重点，从添加标记到利用工程化工具自动解决。
- 对新人要更友好。
- 尽量避免跨时区协作，必要时选择视频会议。
最后，希望 CodeReview 能够得到公司的支持，如果你们公司还没有认可 CodeReview 的价值，可以将这篇文章分享给你的领导。
如果你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。
关注 前端精读微信公众号
版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）