我曾写过一篇关于Code Review的文章《Code Review 最佳实践》，在文章中建议对Code Review的评论进行分级：
建议可以对Review的评论进行分级，不同级别的结果可以打上不同的Tag，比如说：
[blocker]: 在评论前面加上一个[blocker]标记，表示这个代码行的问题必须要修改
[optional]：在评论前面加上一个[optional]标记，表示这个代码行的问题可改可不改
[question]：在评论前面加上一个[question]标记，表示对这个代码行不理解，有问题需要问，被审查者需要针对问题进行回复澄清
类似这样的分级可以帮助被审查者直观了解Review结果，提高Review效率。
当时只是简单的建议分成三个级别：Blocker、Optional和Question，今天看到Netlify的一篇文章《Feedback Ladders: How We Encode Code Reviews at Netlify》，讲到了在Netlify是如何对Code Review的反馈进行阶梯划分的，同时还配有形象的Emoji图标，非常值得学习借鉴。
在这里我简单介绍一下Netlify是如何对Code Review反馈进行分级的。
如果说你的代码是房子，那么这座山⛰️就长在你的房子里面，房子已经被撑破没有空间了，在做其他事情之前必须立即把山给搬了。
⛰️属于最高级别的反馈，问题可能不仅仅是当前PR（Pull Request，合并请求）导致的，而是发现在master的代码有非常严重的问题，属于非常严重并且必须马上修改的级别。
比如说在Review时发现了正在运行的程序中存在的安全漏洞和导致系统崩溃的严重Bug。
如果说你的代码是房子，那么🧗♀️就像是堵在房子门口的巨大石头，非常严重，你不能出门。当然如果你有更紧急的事情，可以先处理更紧急的事情，比如厨房漏水了。
🧗♀️巨石属于严重的问题，不修复当前的PR不能获得批准，但是不影响其他工作任务。
比如说发现当前PR会导致程序性能下降。
如果说你的代码是房子，⚪️就像你房间地板上的鹅卵石，不影响你的正常生活，但是很烦人，可以等有时间的时候清理掉
⚪️属于问题不严重，不影响当前PR的合并，但需要在未来某个时间解决。而且通常这种情况下，最好是在合并PR前，创建一个Ticket来后续跟踪，避免问题不了了之！
比如说在你的PR中，一个颜色有细微的差别，或者漏写了几个测试，那么可以先通过PR，后续再改进，但是最好要创建Ticket跟踪后续改进。
如果说你的代码是房子，那么⏳就像是房间的沙子，你要考虑一下是不是值得清理一下。当然如果你的房子本身就是在沙滩旁边，无论怎么及时清理也总会有沙子跑进来，那么你就没必要时时清理，但是有必要跟你的同事解释清楚。
⏳属于问题不严重，不影响当前PR的合并，但是需要技术负责人考虑是不是需要后续行动，或者做出进一步解释。
比如说在你的PR中，有人建议对代码重构一下以提高可读性。
如果说你的代码是房子，那么🌫就像是房间的灰尘，有人认为值得清理，有人觉得无所谓。
🌫属于可有可无的问题或者建议，不影响PR的合并。后续可做可不做。
比如说在你的PR中，有人对于代码风格和命名上的一些建议。
上面就是对于代码审查的分级，从山⛰️到大石头🧗♀️到小石子⚪️到沙子⏳最后到灰尘🌫，很形象也很实用。
下次你在给团队做代码审查的时候，不妨尝试用上面的分级方式对你的反馈进行分级，这样被反馈的团队成员就很容易知道反馈的级别，从而快速的做出相应的反应。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。