來源

程式碼稽核標準

程式碼稽核的核心目的是保證谷歌程式碼在不斷的改進發展過程中還能持續保證健康。所有程式碼稽核的流程與工具都是設計用於確保這個目標。
為了實現這個目標，我們做了很多的權衡。
首先，研發人員必須能夠在個人的任務上做出改進。如果你從不提交程式碼的改進，那產品就無法提升。同樣的，如果程式碼稽核者對於任何變更提交都設定很高的門檻，也會影響開發者今後也提交改進的熱情。
從另一個方面說，程式碼稽核者的責任是要確保每個變更清單(CL)¹的內容都能夠在全域性上保證程式碼質量，而不會隨著時間導致質量不斷變差。這樣實際上是比較困難的，整體程式碼的質量削弱實際上是由於程式碼健康度中很小的問題不斷累積引發的，特別當一個小組在明確工期的壓力之下，需要走一些捷徑才能夠達成目標。
稽核者對於他們稽核的程式碼是有權利和責任的。他們需要確保程式碼基線是一致風格，可維護，以及在《程式碼稽核應該稽核什麼》一文中提到的其他內容。
所以，我們期望程式碼稽核中包含如下標準規則：
通常情況下，稽核者需要確認一個變更清單對於整體系統程式碼一定是有質量提升的，哪怕目前還不是完美的。
在程式碼稽核的指導規則中，這是最重要的原則。
當然，這條規則存在很多的限制。例如變更清單包含了一個系統不允許加入的特性，即使程式碼的設計和質量很好稽核者也可以直接拒絕。
有一個很重要的觀念，“完美”的程式碼是不存在的，只會有更好

導師制

程式碼稽核者有一個很重要的作用就是指導開發者關於語言、框架、或者軟體設計的通用規則的一些新知識。能夠留下一些評論幫助開發者學習一些新知識總是好事情。分享知識對於程式碼質量改進也是一件好事情。你需要謹記，如果你的評論是處於純粹教育的目的，而不是本文件中提到的評判標準，請加上“Nit:”的字首或者提示提交者這些在變更清單中並非需要強制修改。

原則

• 專業的現實情況與資料否定意見和個人偏好。
• 針對樣式問題，《樣式指南》是絕對權威。任何純粹的樣式觀點（如空格等）在樣式指南中沒有提及的都是個人偏好。這部分的風格也應當統一，如果沒有事先約定則接收提交者的樣式。
• 軟體設計的方面幾乎不可能會是純粹的樣式問題或者個人偏好。 這些都是基於根本性的原則構建的，應當倚重於這些原則，而不是個人意見。有時會存在一些有限的選項。如果提交者能夠證明（通過資料或者基於實際的工程原則）這些做法都是相近的，稽核者應當接受提交者的偏好。否則就要取決於軟體設計的標準規則。
• 如果沒有其他可應用的規則，稽核者應當要求提交者與現有的程式碼基線保持一致，只要變更內容不會影響到系統的健康程度。

解決衝突

面對程式碼稽核中的任何衝突，第一步永遠應該是開發者和稽核者達成一致，原則就是基於本文件和其他的文件如《變更提交者指南》和《稽核者指南》。
當很難達成一致時，提交者和稽核者面對面的溝通或者語音溝通就很有必要，而不是通過程式碼稽核的評論來解決衝突。（但是記住可以將討論的結果以評論的形式記錄在變更提交中，以便將來方便查閱）
如果上面的方法還是不能解決衝突，常見的方法就是升級問題。升級的方法通常是發起團隊會議，要求技術領導參與其中，徵詢程式碼維護者或者管理者的意見，最終做出決策。不要因為提交者和稽核者無法達成一致而閒置一份提交。

下一篇預告：程式碼稽核時，我們應當尋找什麼內容。

總結：
谷歌的程式碼稽核中，首先要建立的是原則，編碼樣式、軟體設計等等的原則。基於這些原則才能判定系統程式碼的健康程度，不是以個人喜好或者使用了某種框架。
稽核者有拒絕提交的權利，但是揹負著系統改進提升和維持健康程度的責任。要熟悉企業的各種原則產生自己的判斷，並且將自己的意見分為必須和建議兩種等級。
面對衝突時，不應當是提交者或者稽核者某一方面的責任，而是雙方應當據理力爭嘗試說服對方，當相互無法說服時可以升級問題，請求上級或者外部來評判。
在這些裡面，所有的角色都有一個很重要的原則：真正的尊重程式碼，熱愛程式碼。而不是隨便糊弄任務，隨便提交，隨便稽核，隨便通過並且合併。這個要靠團隊的文化和企業的健康來支撐。