代碼品質管控的四個階段

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

背景

本文討論的代碼品質指的是代碼本身的品質，包括複雜度、重複率、代碼風格等要素。代碼是團隊的共同財產，代碼品質是團隊技術水平和管理水平的直接體現。

代碼品質下降通常會自成因果，導致惡性迴圈：

• 破窗效應：在爛代碼上繼續生產爛代碼的心理負擔小很多
• 傳染性：爛代碼傳遞著一種不在意品質，只看業務成果的負面資訊，會傷害團隊的技術熱情和工作氛圍，導致更多爛代碼出現

本文會分析代碼品質下降的內在機制，並分享在代碼品質管控方面的一些實踐經驗。

熵增定律與代碼品質

熵增定律告訴我們，一個封閉系統總是趨向於熵增，也就是系統的無序程度只會不斷增加。

對於軟體項目來說，代碼品質代表著系統的有序程度，爛代碼增加就是系統無序性上升的體現。在無外力影響的情況下，爛代碼只會原來越多。

為了維持系統有序，需要外界向系統不斷輸入能量。對於代碼品質，我們需要主動投入資源，來有意識地抑制爛代碼越來越多的自然趨勢。

經典迴圈

爛代碼產生的常見原因是業務壓力大，導致沒有時間或意願講究代碼品質。因為向業務壓力妥協而生產爛代碼之後，開發效率會隨之下降，導致業務壓力更大，形成一種典型的惡性迴圈。

為了應對業務壓力，常見的做法就是向項目中增加人力，但是單純地增加人力的話，會因為風格不一致、溝通成本上升等原因導致爛代碼更多。

要遏制這種惡性迴圈，需要多管齊下，主動對代碼品質進行管控，並且持續進行技術升級，系統性地解決問題。

不過品質管控和技術升級需要長期投入才能產生效果。通常情況下人們還是傾向於通過增加人力快速地解決業務壓力的問題，而忽略了對於代碼品質的負面影響，導致代碼品質越來越差。

四個階段

我把代碼品質管控通常需要經曆的四個階段，稱之為“四個現代化”：

• 正常化 - 建立代碼規範與Code Review制度
• 自動化 - 使用工具自動檢查代碼品質
• 流程化 - 將代碼品質檢查與代碼流動過程綁定
• 中心化 - 以團隊整體為視角，集中管理代碼規範，並實現品質狀況透明化

階段一：正常化

保障代碼品質的基礎是建立團隊的代碼規範，通常包括：

• 風格規範 - 縮排、換行、大小寫等風格問題
• 實踐規範 - 規避一些常見的隱患，或者針對特定問題的最佳實務
• 業務規範 - 與業務有關的特殊要求，比如文案中的關鍵詞

團隊的代碼規範通常以文檔的形式存在，供新人們學習。但文檔這種形式常見的情況就是新人看過之後就不再回顧了，也很難對實際寫代碼形成真正的約束。

在規範的基礎上，要通過Code Review將規範落地。Code Review中大家可以對代碼品質問題進行交流，並且相互監督，形成團隊重視代碼的習慣。

關於Code Review可以參考另一篇文章：Code Review體系與團隊文化

階段二：自動化

自動化是指在代碼規範的基礎上，使用自動化工具進行品質檢查，通常包括：

• 代碼規範檢查 - 包括風格規範、實踐規範、業務規範
• 重複率 - 重複出現的代碼區塊佔比，通常要求在5%以下
• 複雜度 - 總行數，模組大小，迴圈複雜度等
• 檢查覆蓋度 - 經過檢查的行數占程式碼程式庫總行數的比例

自動化品質檢查可以覆蓋多數常見問題，能夠提升開發效率，也可以降低人工Code Review的成本。

自動化檢查工具的規則集與代碼規範直接對應。通過編輯器外掛程式，在寫代碼的時候直接給出檢查結果。到這個階段，團隊的代碼規範文檔已經不再需要陳述各種細節，開發人員可以直接通過查看自動化工具的規則集來瞭解代碼規範。

階段三：流程化

流程化的意思是將自動化代碼品質檢查和Code Review與代碼流動的過程綁定，從而保證所有上線的代碼都經過機器與人工多個環節的檢查。

代碼流動過程：

執行自動化代碼品質檢查的時機：

• 編輯時 - 使用編輯器外掛程式，即時運行品質檢查
• 構建時 - 在本地或者開發機的構建指令碼中運行品質檢查
• 提交時 - 利用Git Hooks，提交代碼或者產生Pull Request時運行品質檢查
• 發布時 - 在發布指令碼中再做一次品質檢查，通常與自動化測試放在一起

品質檢查與代碼流動綁定後的效果：

除了人工的Code Review之外，各個環節的代碼品質檢查都是機器自動啟動並執行，不會給開發人員帶來額外的成本。

階段四：中心化

當團隊規模越來越大，項目越來越多時，代碼品質管控就會面臨以下問題：

• 不同項目使用的代碼規範不一樣
• 部分項目由於放鬆要求，沒有接入品質檢查，或者存在大量未修複的缺陷
• 無法從團隊整體層面上體現各個項目的品質狀況對比

為了應對以上問題，需要建設中心化的代碼品質管控體系，要點包括：

• 代碼規範統一管理。使用Git或者NPM包管理自動化代碼品質檢查的規則集，自動安裝，不在本地寫規則。一個團隊、一類項目、一套規則。
• 使用統一的持續整合服務。品質檢查不通過的項目不能上線。
• 建立代碼品質評分制度。讓項目與項目之間能夠橫向對比，項目自身能夠縱向對比，並且進行匯總反饋。

總結

在面臨業務壓力時，人們通常會傾向於通過增加人力來緩解業務壓力。但從系統整體的角度來看，人力增加會造成代碼品質變差，開發效率下降，從而再度增大業務壓力。這種代碼品質越來越差的迴圈，是熵增定律在軟體工程領域的生動體現。

為了抑制這種迴圈，我們需要有意識地投入資源來建設代碼品質的管控體系。這個過程分為四個階段：正常化，自動化，流程化，中心化。每個階段都有不同關注的要點。

目前我們團隊正在建設代碼品質檢測中心，是中心化品質管控的一種實踐，已經接入幾十個項目在進行試驗。關於中心化建設的細節，我會在後續的文章中繼續闡述。