代碼質量管控的四個階段

背景

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

代碼質量降低一般會自成因果，致使惡性循環：

• 破窗效應：在爛代碼上繼續生產爛代碼的心理負擔小不少
• 傳染性：爛代碼傳遞着一種不在乎質量，只看業務成果的負面信息，會傷害團隊的技術熱情和工做氛圍，致使更多爛代碼出現

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

熵增定律與代碼質量

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

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

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

經典循環

爛代碼產生的常見緣由是業務壓力大，致使沒有時間或意願講究代碼質量。由於向業務壓力妥協而生產爛代碼以後，開發效率會隨之降低，致使業務壓力更大，造成一種典型的惡性循環。

爲了應對業務壓力，常見的作法就是向項目中增長人力，可是單純地增長人力的話，會由於風格不一致、溝通成本上升等緣由致使爛代碼更多。

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

不過質量管控和技術升級須要長期投入才能產生效果。一般狀況下人們仍是傾向於經過增長人力快速地解決業務壓力的問題，而忽略了對於代碼質量的負面影響，致使代碼質量愈來愈差。

四個階段

我把代碼質量管控一般須要經歷的四個階段，稱之爲「四個現代化」：

• 規範化 - 創建代碼規範與Code Review制度
• 自動化 - 使用工具自動檢查代碼質量
• 流程化 - 將代碼質量檢查與代碼流動過程綁定
• 中心化 - 以團隊總體爲視角，集中管理代碼規範，並實現質量情況透明化

階段一：規範化

保障代碼質量的基礎是創建團隊的代碼規範，一般包括：

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

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

在規範的基礎上，要經過Code Review將規範落地。Code Review中你們能夠對代碼質量問題進行交流，而且相互監督，造成團隊重視代碼的習慣。

關於Code Review能夠參考另外一篇文章：Code Review體系與團隊文化

階段二：自動化

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

• 代碼規範檢查 - 包括風格規範、實踐規範、業務規範
• 重複率 - 重複出現的代碼區塊佔比，一般要求在5%如下
• 複雜度 - 總行數，模塊大小，循環複雜度等
• 檢查覆蓋度 - 通過檢查的行數佔代碼庫總行數的比例

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

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

階段三：流程化

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

代碼流動過程：

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

• 編輯時 - 使用編輯器插件，實時運行質量檢查
• 構建時 - 在本地或者開發機的構建腳本中運行質量檢查
• 提交時 - 利用Git Hooks，提交代碼或者生成Pull Request時運行質量檢查
• 發佈時 - 在發佈腳本中再作一次質量檢查，一般與自動化測試放在一塊兒

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

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

階段四：中心化

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

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

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

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

總結

在面臨業務壓力時，人們一般會傾向於經過增長人力來緩解業務壓力。但從系統總體的角度來看，人力增長會形成代碼質量變差，開發效率降低，從而再度增大業務壓力。這種代碼質量愈來愈差的循環，是熵增定律在軟件工程領域的生動體現。

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

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