想要做好程式碼質量，如何破局？

作者：苗現方

想要做好程式碼質量，我們不得不提什麼是程式碼質量？本文中討論的程式碼質量一般是指程式碼的風格、重複率和複雜度等，程式碼是技術團隊的價值產物，是寶貴的財富，同樣程式碼質量的好壞可以直接體現出團隊的重視程度和技術管理水平。

程式碼質量的下降是內在原因，通常會惡性迴圈，主要表現出以下兩個特性：

感染性：壞程式碼總能在部門渲染著只要業務交付達成，程式碼質量不重要的負面氣氛，嚴重減低了研發人員的技術熱情，破壞工作氛圍，導致更多的壞程式碼出現。

心理暗示性：在壞程式碼基礎上繼續生產壞程式碼的"罪過"減輕。

為什麼會產生這樣的結果，這裡我與你舉個生活中的栗子，我在上個週日收拾房間，發現一個房間衣櫃中的衣服很亂，花了很長時間才疊放好，過兩天晚上下班回家，我發現客廳沙發上也很亂，衣服、電腦、揹包、零食幾乎日常的小物件都會有，兩件事情合在一起想，這確實是一個很有趣的思考，為什麼會是這樣的？在一個相對封閉的空間中，任其無意識地隨著時間的發展，房間和沙發也一定很亂，注意，這裡我說的是無意識，也就是我並沒有刻意放，或者去刻意整理。帶著這個思考的結果，我又觀察了大家的工位、園區內景觀，一段時間內一定會出現亂象，不過通過一頓治理之後很快恢復到有秩序，好，大家可以猜到這是什麼定律，就是熵增定律，不瞭解的可以自行網路科普，那麼在質量域中依然存在這樣的定律，不然熵增定律也不會被古今中外的物理學家所推崇備至，它的定義是：在一個孤立系統裡，如果沒有外力做功，其總混亂度（即熵）會不斷增大。

程式碼質量在軟體專案是一種有序的狀態，自然總是向著無序發展的，要想保持這種有序，需要主動投入資源，就像整理房間，花草修剪一樣。

回到我們的多數開發工作中，我們面臨的現狀是這樣的：

1、業務交付壓力大，需求優先上線，業務邏輯實現優先順序最高，沒時間沒精力關注程式碼質量，甚至終極目標就是需求上線，導致壞程式碼產生，開發效率逐步下降，隨著後續版本的迭代，業務交付壓力越來越大。

2、出現了1的情況後，我們意識到壓力越來越大，為了應付這種交付壓力，常見的手段就是增加人力，但是一味的增加人數，溝通成本及風格的一致性無法得到保障，這將進一步產生更多的壞程式碼。

針對以上2個現狀，我們該怎麼著手解決。

我的建議方案是多渠道，系統性解決問題，首先控制人力的大量投入，主動發起對程式碼質量進行管控，其次持續提升技術升級。但是，從減輕業務交付壓力的結果來看，人們往往傾向於增加人力來快速解決問題，技術升級需要靠長期的投入才能有所收穫，所以，我們需要在質量方面增加強有力的管控。

如果做好程式碼質量管控？

程式碼質量管控首先應解決兩個問題，庫存壞程式碼和增量壞程式碼。

想解決這兩個問題，我們要對現有的系統、人員、工具、流程整合形成一套體系化的方案。

對程式碼質量管控，通過在部門內工程實踐，我認為需要經歷以下這四個過程，部門內建立程式碼規範制度（EOS）、檢查程式碼問題的自動化工具（bamboo平臺）、程式碼質量檢查與程式碼流動過程繫結（質量門禁）、部門視角下，集中管理程式碼規範和質量狀況的透明（程式碼質量評測系統）。

過程一：程式碼質量的基礎是規範，包括程式碼風格的規範、長期一執行緒式碼實踐規範、與業務需求相關的特殊規範，例如風控文案、異常託底文案等。

過程二：實現自動化的檢查能力是在規範基礎之上，通過自動化工具進行檢查，包括對程式碼重複率、圈複雜度、單測case通過率、靜態規則掃描等。

過程三：實現質量檢查與程式碼流動過程繫結，在編輯-構建-提交-釋出各個時段部署檢查能力保障上執行緒式碼必須經過機器和人工的多環節檢查。

過程四：團隊規模逐步擴大，各業務線專案快速發展，實現規範管理統一、專案要求一致、各專案質量狀況透明、對比，建立統一的評測體系。

為了讓你有一個很直觀的認識，我在下面畫了一個張圖，希望可以幫你快速理解。

總結：

在日常開發工作中，大家都會想到通過增加人手來緩解專案交付的壓力，這是可以理解，但是從整體角度看，人員的增加會產生越來越多的壞程式碼，使整體的效率下降，這又進而加劇了後續專案交付的壓力，在這種壓力下，又通過增加人手緩解......讓程式碼質量變的越來越差，這也是房間為什麼會越來越亂，是熵增定律在軟體質量域的生動體現。

為了抑制這種惡性迴圈，我們意識到了通過有效的手段和資源投入進行各項工程實踐，逐步完善程式碼質量的管控體系，積累很多方法和工具。

目前，我也在積極探索對統一程式碼質量評測體系的實踐，希望逐步建立一套中心化的程式碼質量評測系統，在這個系統中讓工匠精神、專家文化借住平臺進一步傳播、讓系統的質量更加透明。有關評測的具體實踐，我在後續的文章中與大家分享。