如何对 Code Review 的评论进行分级

用户头像
宝玉
关注
发布于: 2020 年 05 月 06 日
如何对Code Review的评论进行分级

我曾写过一篇关于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中,有人对于代码风格和命名上的一些建议。



总结

上面就是对于代码审查的分级,从山⛰️到大石头🧗‍♀️到小石子⚪️到沙子⏳最后到灰尘🌫,很形象也很实用。



下次你在给团队做代码审查的时候,不妨尝试用上面的分级方式对你的反馈进行分级,这样被反馈的团队成员就很容易知道反馈的级别,从而快速的做出相应的行动。





发布于: 2020 年 05 月 06 日 阅读数: 60
用户头像

宝玉

关注

还未添加个人签名 2018.03.13 加入

还未添加个人简介

评论

发布
暂无评论
如何对Code Review的评论进行分级