我曾寫過一篇關於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中，有人對於代碼風格和命名上的一些建議。
總結
上面就是對於代碼審查的分級，從山⛰️到大石頭🧗♀️到小石子⚪️到沙子⏳最后到灰塵🌫，很形象也很實用。
下次你在給團隊做代碼審查的時候，不妨嘗試用上面的分級方式對你的反饋進行分級，這樣被反饋的團隊成員就很容易知道反饋的級別，從而快速的做出相應的反應。