精读《如何作好 CodeReview》

1 引言

任何软件都是协同开发的，因此 CodeReview 很是重要，它能够帮助你减小代码质量问题，提升开发效率，提高稳定性，同时还能保证软件架构的稳定性，防止代码结构被恶意破坏致使难以维护。

因此 CodeReview 机制是否健全是一个工程团队可否长期健康发展的决定因素之一，此次咱们读一篇关于 CodeReview 如何作得更好的文章： how-to-make-good-code-reviews-better。

2 概述 & 精读

做者结合本身在 Uber、微软的工做经历介绍了本身对如何作好 CodeReview 的见解。

CodeReview 的覆盖范围

Good CodeReview 会检查代码的正确性、测试覆盖率、功能变化、是否遵循代码规范与最佳实践、能够指出一些较为明显的改进点，好比难以阅读的写法、未使用到变量、一些边界问题、commit 数量过大须要拆分等等。

Better CodeReview 会检查引入代码的必要性，与已有系统是否适配，是否具备可维护性，从抽象角度思考代码是否与已有系统逻辑可以自洽。

Better CodeReview 会关注在可维护性层面，并具备全局性，每每几个局部正确的代码组合在一块儿会产生错误的结果，或者是不必的代码，或者是相互冲突的逻辑。Better CodeReview 更多用在底层架构场景，由于架构底层模块关联比较紧密，须要有总体视角，而业务上层模块间最好采用解耦模式，这样不只不须要更耗费精力的 Better CodeReview，也是一种更正确的架构设计。

CodeReview 的语气

Good CodeReview 会给出建设性意见，而不是发表强硬措辞要求对方改正，或认为本身的意见是惟一正确的答案，由于这样的评论其实具备必定攻击性，激发对方的防护心理，产生敌对心态，这样会从内部瓦解一个团队。最好能给出建议，或者多个选择，给对方留有余地。

Better CodeReview 永远是考虑全面且正向积极的，会对写的好的地方进行鼓励，对写的很差的地方也体现出善解人意的关怀，考虑到对方可能花费了不少心血，以一种换位思考的鼓励心态进行评论。

其实读到语气这一章节，逐渐发现 CodeReview 不只是一个技术专业行为，仍是一我的与人相处的社交行为，有的人平时与人打交道很是谦逊，但在 CodeReview 中就变得尖酸刻薄，显然是只关注到了 CodeReview 的专业性这一面，忽略了社交性这一点。而要作到 Better CodeReview 还要学会换位思考，体现出包容、正向积极的态度，由于你技术经验更丰富，能指出别人的问题很正常，但能保持谦逊，让别人容易接受并受到鼓励，可让你成为一个有气度的技术专家。

如何完成 CodeReview 的审阅

Good CodeReview 不会轻易经过那些开放式 PR，至少在其被获得充分讨论前，但每一个 Review 者对本身关注的部分完成 Review 后须要进行反馈，不管是 “看起来不错” 或者用缩写单词 “LGTM”，以后须要有明确的跟进，好比经过协做软件通知做者进行进一步反馈。

Better CodeReview 实际执行中会更加灵活一些，对于一些比较紧急的改动会留下改进建议，但快速经过，让做者经过后续代码提交解决遗留的问题。

实际工做场景会遇到一些开放式或紧急的提交，良好的 CodeReview 习惯天然是要严谨一些，讨论清楚再经过，而且要及时反馈。但某些比较紧急的提交就要区别对待了，更好的态度是在实践中灵活对待，但及时紧急经过了，也要保证问题在后续得以修复，好比在代码中留一些 "TODO" 或 "FIXME" 的标记，写上对应的负责人与预期解决时间。

从 CodeReview 到直接交流

Good CodeReview 会给出完整的评论和修改建议，若是后续提交的代码不符合预期，Review 者能够直接与代码提交者面对面交流，这样能够避免后续花费更多沟通时间。

Better CodeReview 会在第一次给出完整的评论和修改建议，若是后续提交代码不符合预期，会当即与代码提交者当面沟通，避免异步沟通带来更多的理解误差。

补充一下，在 PR 内容过多时也能够选择直接与提交者当面沟通，这样能够更多理解做者的想法，使 Review 准确性更高。另外并不要每次都直接交流，异步的 CodeReview 自己就是一种提效方案，这会使你工做节奏把握在本身手中，仅在这种方案出现沟通问题时再选择当面交流。

区分重点

Good CodeReview 能够区分提示的重要程度，并在不过重要的改动前面加上 “nit:” 标记，这样可使提交者的注意力集中在重要的问题上。

Better CodeReview 会采起工具手段解决这些问题，好比一些代码 lint 工具，由于这些问题每每是能够被工具自动化解决的。

代码自动化工具的目的，很大一部分也是为了保证代码一致性，从而下降 CodeReview 成本，也减小不重要的评论信息出现，让 CodeReview 尽量反馈逻辑问题而不是格式问题。

针对新人的 CodeReview

Good CodeReview 对任何人都是用相同评判标准，能够遵循上面几点注意事项。

Better CodeReview 会对新人区分对待，对新人给予对多的耐心、解释和评论，甚至给出解决方法，并更积极的给出鼓励。

任何人到一家新公司都有适应过程，一视同仁是 base 要求，但若是能给予新人更多关怀就更好啦。

跨办公区、时区的 CodeReview

Good CodeReview 仅在工做时间有重叠的时间范围内进行 CodeReview，这样能保证对方能够积极响应，在必要时进行语音、视频沟通。

Better CodeReview 会注意到更本质的问题，留意跨团队协做的必要性，若是某个模块常常被另外一个时区同时修改，也许能够将这个模块交给对方维护，或者将 CodeReview 交给对方团队内部进行会更加高效。

笔者所在公司也有跨时区协做状况，但绝大部分场景会避免跨时区的 CodeReview，由于 CodeReview 通常会在同一时区团队内部进行，这样效率更高，应对跨时区协做时，每每也是电话、视频会议优先。

公司支持

Good CodeReview 会获得公司组织支持，公司能意识到这么作虽然看起来占用开发时间，但长远来看提高了开发效率，所以能任何 CodeReview 价值。

Better CodeReview 会获得公司进一步支持，公司甚至不断研发并完善 CodeReview 系统与流程，经过系统化方案保证上面几项 CodeReview 注意事项是否有在团队内落实，能够全员参与。

CodeReview 也是一种团队文化和公司文化，公司文化带来的是规章制度与系统工具，团队文化带来的是良好 CodeReview 氛围与更高 CodeReview 的效率。

3 总结

总结一下，良好的 CodeReview 须要作到如下几点：

1. 更全面，从正确性到系统影响评估。
2. 注意语气，从给出建设性一觉到换位思考。
3. 及时完成审阅，从充分讨论到随机应变。
4. 增强交流，从面对面交流到灵活选择最高效的沟通方式。
5. 区分重点，从添加标记到利用工程化工具自动解决。
6. 对新人要更友好。
7. 尽可能避免跨时区协做，必要时选择视频会议。

最后，但愿 CodeReview 可以获得公司的支持，若是大家公司尚未承认 CodeReview 的价值，能够将这篇文章分享给你的领导。

讨论地址是： 精读《如何作好 CodeReview》 · Issue #237 · dt-fe/weekly

若是你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明：自由转载-非商用-非衍生-保持署名（ 创意共享 3.0 许可证）