評審目的

程式碼評審的目的就是為了保證公司整體程式碼的健康狀況隨著不斷迭代，始終保持一個較高的水平，所有在評審中使用的工具和流程都應是為此目的而設計的。

評審原則

• 鼓勵質疑
• 保持程式碼風格，遵守開發規範
• 優先設計原則，尊重個人偏好
• 重視每一行程式碼
• 儘可能採用面對面的形式

評審時機

研發流程應該是嚴密的、有節奏的，而個體的程式碼質量會影響整體交付進度，所以請第一時間啟動程式碼評審，最晚不要超過早期測試階段。

如果是非同步評審的機制，評審過程最好不要超過一個工作日，如果評審時間較長，請在開始評審時進行初步反饋。

評審範圍

1. 功能

這個Change List是否達到了預期目標？

併發、資料許可權、效能、競態條件等一系列邊緣異常是否合理規避？

2. 複雜性

新增的複雜是否是值得的？

複雜設計的實現是否是可讀的？

抽象定義是否是優雅整潔的？

鼓勵透過設計提高可擴充套件性，但不可“面向未來做設計”，二者之間的界限應該是：是否能夠看到明確的演進方向（actual shape）和需求

3. 單元測試

是否有單元測試？

單元測試是否具有良好的可讀性？

每一個測試是否有斷言？

是否能覆蓋儘可能多的邏輯分支？

4. 命名

命名是否符合規範，且具有良好可讀性？

命名是否能充分表達一個項是什麼、用來做什麼？

5. 註釋

註釋內容是否是必須的？

註釋資訊是否全面表述對應程式碼的意義？如果發現註釋難以解釋這段程式碼，那麼很大機率上這段程式碼應該簡化或者重構。

註釋資訊應表達程式碼的用處，而不是解釋程式碼在幹什麼

6. 程式碼風格

鼓勵對程式碼風格提出改進建議，但請提及這是一項錦上添花的建議，切不可作為評審透過與否的判定條件。

如果使用評審工具，請在評論前標註Nit:，以標識這是一項Nitpick（吹毛求疵）的建議。

7. 文件

是否同時建立了或修改了相關文件？

文件格式是否與原專案保持一致？

8. 上下文

修改的內容是否影響原業務邏輯的上下游依賴？

修改的內容是否導致程式碼質量下降，甚至系統架構腐化？

9. 優秀的程式碼設計

請不要忽略change list中你覺得不錯的部分，肯定優秀設計比指出錯誤更有價值。

評審尺度

不要為了提高評審速度而犧牲程式碼評審的標準，團隊內的程式碼評審應該是一個持續改進的過程，發現問題、解決問題、避免問題，這種正向迴圈會為研發流程的每一步都帶來收益。

如果因為各種原因確實需要加速評審環節，可以按照重要程度降低一部分評審標準。但請在合適的時間，對這部分程式碼進行重新評審，專案進度緊張不應成為降低程式碼質量的理由。

如何解決評審意見衝突

評審是對他人工作進行評判，難以避免意見相左的情況發生，通常研發人員會有非常多的理由拒絕評審建議。

1. 誰是對的

如果研發人員認為評審結果有問題，評審人員請優先思考開發者是不是對的，畢竟他們“離程式碼更近”。

如果評審人員認為評審結果是正確的，合理、適當、禮貌的討論，會讓真相更清晰。

研發人員的反感情緒通常是因為提出問題的方式，而不是對程式碼質量的堅持。

2. 稍後再解決

研發人員最常見的拒絕原因，就是進度緊張，希望能夠先做妥協，承諾後續修正。

但通常之後不會再去做這件事，這並非完全是責任心的問題，而是因為研發人員通常非常繁忙，修復這件事就容易被遺忘。

所以最好將評審建議儘快修復。

3. 評審過於嚴格

如果評審尺度嚴格導致研發人員抱怨，那麼禮貌的堅持非常有必要，嚴格的程式碼評審有助於產出優秀的程式碼。

可能過了很長時間後研發人員才能看到這部分程式碼評審的價值，經過論證後的價值觀一致更容易建立彼此的認同感。

總結

程式碼評審是一項具有長期價值的工作，並且對評審雙方都具備價值。不要懼怕提出問題，這更容易提高你對問題的認知，如果最終發現你提出的問題是錯誤的，這對你也是一項難得的提高。更不要拒絕修改問題，即使這些問題在你看來微不足道，反覆的正向行為形成慣性，更容易提高工作質量。

參考：

1. https://google.github.io/eng-practices/review

作者：康志興