背景
本文討論的程式碼質量指的是程式碼本身的質量，包括複雜度、重複率、程式碼風格等要素。程式碼是團隊的共同財產，程式碼質量是團隊技術水平和管理水平的直接體現。
程式碼質量下降通常會自成因果，導致惡性迴圈：
- 破窗效應：在爛程式碼上繼續生產爛程式碼的心理負擔小很多
- 傳染性：爛程式碼傳遞著一種不在意質量，只看業務成果的負面資訊，會傷害團隊的技術熱情和工作氛圍，導致更多爛程式碼出現
本文會分析程式碼質量下降的內在機制，並分享在程式碼質量管控方面的一些實踐經驗。
熵增定律與程式碼質量
熵增定律告訴我們，一個封閉系統總是趨向於熵增，也就是系統的無序程度只會不斷增加。
對於軟體專案來說，程式碼質量代表著系統的有序程度，爛程式碼增加就是系統無序性上升的體現。在無外力影響的情況下，爛程式碼只會原來越多。
為了維持系統有序，需要外界向系統不斷輸入能量。對於程式碼質量，我們需要主動投入資源，來有意識地抑制爛程式碼越來越多的自然趨勢。
經典迴圈
爛程式碼產生的常見原因是業務壓力大，導致沒有時間或意願講究程式碼質量。因為向業務壓力妥協而生產爛程式碼之後，開發效率會隨之下降，導致業務壓力更大，形成一種典型的惡性迴圈。
為了應對業務壓力，常見的做法就是向專案中增加人力，但是單純地增加人力的話，會因為風格不一致、溝通成本上升等原因導致爛程式碼更多。
要遏制這種惡性迴圈，需要多管齊下，主動對程式碼質量進行管控，並且持續進行技術升級，系統性地解決問題。
不過質量管控和技術升級需要長期投入才能產生效果。通常情況下人們還是傾向於通過增加人力快速地解決業務壓力的問題，而忽略了對於程式碼質量的負面影響，導致程式碼質量越來越差。
四個階段
我把程式碼質量管控通常需要經歷的四個階段，稱之為“四個現代化”：
- 規範化 - 建立程式碼規範與Code Review制度
- 自動化 - 使用工具自動檢查程式碼質量
- 流程化 - 將程式碼質量檢查與程式碼流動過程繫結
- 中心化 - 以團隊整體為視角，集中管理程式碼規範，並實現質量狀況透明化
階段一：規範化
保障程式碼質量的基礎是建立團隊的程式碼規範，通常包括：
- 風格規範 - 縮排、換行、大小寫等風格問題
- 實踐規範 - 規避一些常見的隱患，或者針對特定問題的最佳實踐
- 業務規範 - 與業務有關的特殊要求，比如文案中的關鍵詞
團隊的程式碼規範通常以文件的形式存在，供新人們學習。但文件這種形式常見的情況就是新人看過之後就不再回顧了，也很難對實際寫程式碼形成真正的約束。
在規範的基礎上，要通過Code Review將規範落地。Code Review中大家可以對程式碼質量問題進行交流，並且相互監督，形成團隊重視程式碼的習慣。
關於Code Review可以參考另一篇文章：Code Review體系與團隊文化
階段二：自動化
自動化是指在程式碼規範的基礎上，使用自動化工具進行質量檢查，通常包括：
- 程式碼規範檢查 - 包括風格規範、實踐規範、業務規範
- 重複率 - 重複出現的程式碼區塊佔比，通常要求在5%以下
- 複雜度 - 總行數，模組大小，迴圈複雜度等
- 檢查覆蓋度 - 經過檢查的行數佔程式碼庫總行數的比例
自動化質量檢查可以覆蓋多數常見問題，能夠提升開發效率，也可以降低人工Code Review的成本。
自動化檢查工具的規則集與程式碼規範直接對應。通過編輯器外掛，在寫程式碼的時候直接給出檢查結果。到這個階段，團隊的程式碼規範文件已經不再需要陳述各種細節，開發者可以直接通過檢視自動化工具的規則集來了解程式碼規範。
階段三：流程化
流程化的意思是將自動化程式碼質量檢查和Code Review與程式碼流動的過程繫結，從而保證所有上線的程式碼都經過機器與人工多個環節的檢查。
程式碼流動過程：
執行自動化程式碼質量檢查的時機：
- 編輯時 - 使用編輯器外掛，實時執行質量檢查
- 構建時 - 在本地或者開發機的構建指令碼中執行質量檢查
- 提交時 - 利用Git Hooks，提交程式碼或者生成Pull Request時執行質量檢查
- 釋出時 - 在釋出指令碼中再做一次質量檢查，通常與自動化測試放在一起
質量檢查與程式碼流動繫結後的效果：
除了人工的Code Review之外，各個環節的程式碼質量檢查都是機器自動執行的，不會給開發者帶來額外的成本。
階段四：中心化
當團隊規模越來越大，專案越來越多時，程式碼質量管控就會面臨以下問題：
- 不同專案使用的程式碼規範不一樣
- 部分專案由於放鬆要求，沒有接入質量檢查，或者存在大量未修復的缺陷
- 無法從團隊整體層面上體現各個專案的質量狀況對比
為了應對以上問題，需要建設中心化的程式碼質量管控體系，要點包括：
- 程式碼規範統一管理。使用Git或者NPM包管理自動化程式碼質量檢查的規則集，自動安裝，不在本地寫規則。一個團隊、一類專案、一套規則。
- 使用統一的持續整合服務。質量檢查不通過的專案不能上線。
- 建立程式碼質量評分制度。讓專案與專案之間能夠橫向對比，專案自身能夠縱向對比，並且進行彙總反饋。
總結
在面臨業務壓力時，人們通常會傾向於通過增加人力來緩解業務壓力。但從系統整體的角度來看，人力增加會造成程式碼質量變差，開發效率下降，從而再度增大業務壓力。這種程式碼質量越來越差的迴圈，是熵增定律在軟體工程領域的生動體現。
為了抑制這種迴圈，我們需要有意識地投入資源來建設程式碼質量的管控體系。這個過程分為四個階段：規範化，自動化，流程化，中心化。每個階段都有不同關注的要點。
目前我們團隊正在建設程式碼質量檢測中心，是中心化質量管控的一種實踐，已經接入幾十個專案在進行試點。關於中心化建設的細節，我會在後續的文章中繼續闡述。