代碼質量管控的四個階段

背景

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

代碼質量下降通常會自成因果，導致惡性循環：

破窗效應：在爛代碼上繼續生產爛代碼的心理負擔小很多

傳染性：爛代碼傳遞著一種不在意質量，只看業務成果的負面信息，會傷害團隊的技術熱情和工作氛圍，導致更多爛代碼出現

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

熵增定律與代碼質量

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

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

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

經典循環

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

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

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

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

四個階段

我把代碼質量管控通常需要經歷的四個階段，稱之為「四個現代化」：

規範化 - 建立代碼規範與Code Review制度

自動化 - 使用工具自動檢查代碼質量

流程化 - 將代碼質量檢查與代碼流動過程綁定

中心化 - 以團隊整體為視角，集中管理代碼規範，並實現質量狀況透明化

階段一：規範化

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

風格規範 - 縮進、換行、大小寫等風格問題

實踐規範 - 規避一些常見的隱患，或者針對特定問題的最佳實踐

業務規範 - 與業務有關的特殊要求，比如文案中的關鍵詞

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

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

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

階段二：自動化

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

代碼規範檢查 - 包括風格規範、實踐規範、業務規範

重複率 - 重複出現的代碼區塊佔比，通常要求在5%以下

複雜度 - 總行數，模塊大小，循環複雜度等

檢查覆蓋度 - 經過檢查的行數占代碼庫總行數的比例

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

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

階段三：流程化

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

代碼流動過程：

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

編輯時 - 使用編輯器插件，實時運行質量檢查

構建時 - 在本地或者開發機的構建腳本中運行質量檢查

提交時 - 利用Git Hooks，提交代碼或者生成Pull Request時運行質量檢查

發布時 - 在發布腳本中再做一次質量檢查，通常與自動化測試放在一起

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

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

階段四：中心化

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

不同項目使用的代碼規範不一樣

部分項目由於放鬆要求，沒有接入質量檢查，或者存在大量未修復的缺陷

無法從團隊整體層面上體現各個項目的質量狀況對比

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

代碼規範統一管理。使用Git或者NPM包管理自動化代碼質量檢查的規則集，自動安裝，不在本地寫規則。一個團隊、一類項目、一套規則。

使用統一的持續集成服務。質量檢查不通過的項目不能上線。

建立代碼質量評分制度。讓項目與項目之間能夠橫向對比，項目自身能夠縱向對比，並且進行匯總反饋。

總結

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

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

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

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！