怎麼提升代碼質量？-來自Google的研發經驗總結

關注個人微信公衆號：小爭哥，獲取更多、更新的技術、非技術分享。
做者：前Google工程師，5萬人訂閱《數據結構和算法之美》專欄做者。
但願經過我加速你的技術、職場進步。

你的團隊有沒有過這樣的經歷：開發效率低，招了不少人，每天加班，出活卻很少，線上bug頻發，領導發飆，中層一籌莫展，工程師抱怨不斷，查找bug困難。其實這些都是代碼質量差惹的禍。代碼質量是研發質量管理的根本，它決定了整個開發團隊的開發效率，項目質量，其餘監控，告警，日誌等手段都只能是過後補償。本文就如何保證代碼質量總結了一些經驗和方法，供你們參考。

代碼質量自己並無一個特別明確的量化指標，並且根據公司發展的不一樣階段，團隊規模的大小不一樣，項目性質的不一樣等，對代碼質量的要求也不盡相同．不過若是項目中出現如下狀況時候，就說明代碼質量要值得重視了．

添加或修改一個簡單功能時，涉及要修改的地方特別多，並且很分散；

代碼不可複用：類似的功能沒法複用代碼，要從新開發；

線上bug頻發，排錯困難，修復難度大，時間長；

有不少奇怪的代碼，代碼讀不懂，新人沒法很快了解代碼；

代碼中坑特別多，不敢大動，一不當心就踩坑；

以上這些問題，基本上都是代碼質量不高致使的，包括代碼無註釋，無文檔，命名差，項目層次結構差，調用關係混亂，處處hardcode，臨時解決方案等等。怎麼才能時刻保證代碼的高質量，避免以上問題發生？固然團隊的技術素質很重要，除此以外，還有一些方法可循的．

1. 吹毛求疵般地執行編碼規範

嚴格執行代碼編寫規範，可使一個項目乃至一個公司的代碼具備徹底統一的風格，就像同一我的編寫的同樣，並且命名良好的變量，函數，類和註釋，也無疑能夠提升代碼的可讀性．具體落實到執行層面，能夠參照Google的編碼規範或者java官方的編碼規範，網上能夠找到，關鍵是要嚴格遵照，而且在code review時，嚴格要求，沒有按照規範的必定要指出而且要求修改．

實際狀況每每是雖然你們都知道優秀的代碼規範是怎樣的，但在具體寫代碼的過程當中，卻執行的差強人意，不少狀況是認識上不夠重視，以爲一個變量或者函數的命名成哪樣關係不大，因此不夠推敲，註釋不少也都不寫，code review的時候你們也都事不關己心態，或者以爲不必太摳細節，致使慢慢的整個code base變得愈來愈差．因此這裏仍是要強調一下，細節決定成敗，提升團隊對代碼規範的認同及其嚴格的執行是關鍵．

2. 編寫高質量的單元測試

單元測試是最容易執行，且對提升代碼質量見效最快的方法之一還。但仍是有不少公司對單元測試重視不夠，包括一些大的互聯網公司，不寫或者隨便寫寫。

有些工程師以爲有測試團隊就夠了，再寫單元測試就是浪費時間。其實測試團隊的測試和單元測試是在不一樣層面上的，測試團隊的測試通常是黑盒測試，系統層面的集成測試，對於複雜系統來講，組合爆炸，測試團隊沒法窮舉全部的測試用例。單元測試是代碼層面的測試，通常是針對類的測試。既然沒法從系統的總體上保證100%符合咱們的預期，那單元測試起碼能保證咱們代碼在細粒度上運行符合預期。

有些工程師認爲開發任務重沒時間寫。這個仍是沒有足夠重視單元測試，以爲是無關緊要的部分，纔會有這樣的想法。寫好單元測試，節省不少解決線上bug的時間，開發時間反而更充足了。

還有不少工程師雖然在寫單元測試，但只對正常流程作測試。代碼中的bug多數是寫代碼時異常狀況沒有考慮全面致使的，正常流程通常不會出問題。單元測試的做用就在於測試各類異常狀況下代碼的運行是否符合預期，因此只對正常流程測試沒法發揮單元測試真正的做用。

通常狀況下，單元測試代碼量要比要測試的代碼多，通常是1-2倍的樣子，寫單元測試自己沒有太多的技術挑戰，主要看工程師邏輯是否縝密，可以考慮各類異常狀況，寫起來比較枯燥，因此寫高質量的單元測試的一方面要靠工程師的耐心執行，另外一方面要靠團隊的嚴格要求。固然這些都是創建在對單元測試重要性的認同之上。

3. 不流於形式的Code Review

若是說單元測試不少工程師不怎麼重視，那code review就是不怎麼接受．跟不少大型互聯網公司的人聊過，對code review都不怎麼承認，大部分反應都是，這玩意不可能很好的執行，浪費時間，是的，code review作的再流暢，也是要花時間的，關鍵在於咱們是願意花2天寫代碼花5天修bug,仍是願意花３天寫代碼花半天修bug.

其實，code review的好處不只僅是可以大大提升代碼質量，減小代碼bug，你想一想若是咱們沒有code review，平時寫的代碼「偷偷」就commit了，不免有人不自律，有了code review，直播代碼，曝光dirty code，你們就會更認真些．其次來說，code review也是一種有效技術傳幫帶的途徑，每次code review都是一次案例的剖析，能夠幫助初級的工程師培養編碼規範，提升編碼質量，設計能力甚至於架構能力，反過來，review別人寫的好的代碼，對本身也是一種學習和提升．

除此以外，嚴格的code review不只能保證代碼的質量，還能造成良好的技術氛圍。

4. 開發未動文檔先行

編寫技術文檔對大部分工程師來講都是挺反感的事情。通常來說在開發某個系統或者重要模塊或者功能以前須要先寫技術文檔，而後發送給同組或者相關同事審查，在審查沒有問題的狀況下再開發，這樣可以事先達成共識，開發出來的東西不至於走樣，並且當開發完成以後進行code review的階段，代碼審查者經過閱讀開發文檔也能夠快速的理解代碼．

除此以外，文檔對於團隊和公司來說都是重要的財富，對於新人加入公司熟悉代碼，產品，對於任務的交接等等都頗有幫助，並且做爲一個規範化的技術團隊，技術文檔是一種摒棄做坊式開發和我的英雄主義的有效方法，是保證團隊有效協做的途徑．

不過，有不少工程師提出說不會寫技術文檔，不知道寫什麼，但願給一個模板或者目錄．我以前曾經想過是否能夠給出一個固定的模板，但最後仍是放棄了，比較難，難點在於，每一個項目側重點都不同不容易總結，若是硬要給出一個很寬泛的目錄，不具備指導性也沒有意義．大致上來說，文檔的內容主要是將作的東西講清楚，包括出問題背景，解決了什麼問題，外部怎麼用或調用，內部如何實現，大的架構，關鍵功能和算法等，以及一些非功能性的考慮。

5. 持續重構，重構，重構

我的比較反對平時不注重代碼質量，堆砌爛代碼，實在維護不了了就大刀闊斧的重構甚至重寫。有時候項目代碼太多了，重構很難作到完全，最後又搞出來一個四不像的怪物，更麻煩了！

優秀的代碼或架構不是一開始就能徹底設計好的，就像優秀的公司或產品也都是迭代出來的同樣的，咱們沒法100%碰見將來的需求，也沒有足夠的精力，時間，資源爲遙遠的將來買單，因此隨着系統的演進，重構代碼也是不可避免的，雖然上面說了不支持大刀闊斧推到重來式的大重構，但持續的小重構仍是比較推崇的，也是時刻保證代碼質量防止代碼腐化有效手段．簡單一句話就是不要等到問題堆得太多了再採起重構，要時刻有人對代碼總體負責任，平時沒事就改改代碼，而不要以爲重構代碼就是浪費時間，遊手好閒！

特別是一些業務開發團隊，有時候爲了快速完成一個產品或者業務功能，只追求速度，處處hard code，在徹底不考慮非功能性需求的狀況下，堆砌一些爛代碼，這種狀況仍是比較常見的。不過不要緊，等有時間必定要記着重構，否則爛代碼越堆越多，總有一天會沒人能維護。

6. 項目與團隊」微服務化」

只有小項目是能夠維護的，大項目是沒法維護的．團隊人比較少的時候，十幾我的的樣子，代碼量也很少，不超過10萬行，怎麼開發，怎麼管理都沒問題，你們互相都瞭解彼此作的東西，代碼質量太差了，大不了重寫一遍．但若是是一個極其龐大的項目，幾十萬行代碼，幾十個開發維護，那基本上沒人能對代碼負責了．

因此當項目太大了以後，就須要對代碼和團隊進行拆分，模塊化，大團隊拆成幾個小團隊，大項目拆成幾個小項目，這樣每一個團隊每一個項目的代碼都不至於不少，也不至於出現代碼質量太差沒法維護的狀況，其實不少技術也都體現了這種思想，好比大到soa, 微服務，小到jar, .so等lib模塊開發，Class類的封裝，都是一種拆分的思想．

7. 重視代碼關注細節

以上其餘的全部方法都是治標不治本，找到對的人用好對的人，打造優秀的技術文化，纔是能一直卓越的根本。有不少工程師比較熱衷於學習架構，工具，框架層面的東西，見過不少工程師，還沒寫三五年代碼就轉作架構師，不寫代碼了，處處忽悠，很很差，互聯網信息如此透明，不一樣的人去作同一個項目，其實最後設計出來的架構,功能大約都差很少，最後你們都能把這個系統實現，但有些人作出來的系統，bug不少，性能不好，擴展性也很差，最多能叫個POC。

高手之間的競爭仍是在於細節，一個算法夠不夠優化，數據存取的效率高不高，內存是否夠節省等等，這是累積起來決定了一個系統是否是夠優秀。

固然並非說框架，工具，架構設計這些方面的學習不重要，關鍵是有深度，但願是實踐中鍛鍊得來的，而不是處處看微信公衆號，博客得來的。

國內工程師廣泛深度不夠，作幾年技術就轉管理或者純架構設計不寫代碼了，而國外不同，大齡碼農不少，因此國外的優秀開源項目比較多，而國內不多。

8. 工欲善其事必先利其器

代碼中的不少低級質量問題不須要人工去審查，java開發有不少現成的工具可使用，好比：checkstyle，findbugs, pmd, jacaco, sonar等。

Checkstyle,findbugs,pmd是靜態代碼分析工具，經過分析源代碼或者字節碼，找出代碼的缺陷，好比參數不匹配，有歧義的嵌套語句，錯誤的遞歸，非法計算，可能出現的空指針引用等等。三者均可以集成到gradle等構建工具中。

Jacoco是一種單元測試覆蓋率統計工具，也能夠集成到gradle等構建工具中，能夠生成漂亮的測試覆蓋率統計報表，同時Eclipse提供了插件能夠EclEmma能夠直觀的在IDE中查看單元測試的覆蓋狀況。

Sonar Sonar 是一個用於代碼質量管理的平臺。能夠在一個統一的平臺上顯示管理靜態分析，單元測試覆蓋率等質量報告。

最後，總結

以上全部的這些方法論應該都沒啥新奇的，也沒有葵花寶典似的殺手鐗，說出來感受都很簡單的，如今互聯網這麼發達，信息都很透明，因此大方向你們都知道，具體的策略和架構各家也都差很少，最後誰作的好，關鍵在於執行和細節，常常聽到有人說咱們作了單元測試啊，咱們作了性能測試，可最後仍是一堆性能問題一堆bug，那就要去考慮一下到底作的夠不夠好，是否作到了具體問題具體分析，不生搬硬套，從決策到執行再到考覈是否造成了閉環，不少時候只是空喊口號，口號喊得100分，落實到執行只能得５0分，最後又徹底沒考覈，好壞你們也都不知，切記敏於言而訥於行。