提高程式碼質量的12個技巧

本文由碼農網 – 小峰原創翻譯，轉載請看清文末的轉載要求，歡迎參與我們的付費投稿計劃！

正如我曾在以前的帖子中提到過，我最近正在教授學生有關於精益軟體開發的課程。其中一個我提出的觀點就是：質量免費（或者至少能變得便宜）的前提是，我們得先致力於提高質量。

1.測試驅動開發（TDD）

如果說要找一個最能提高程式碼質量同時還要減少bug的實踐練習恐怕就非TDD莫屬了。它的優點是適用於任何型別的專案和敏捷開發。其歷史可以追溯到很早以前，但是直到XP的普及它才漸漸為人所知。當作為能自動化構建和測試實踐的持續整合周期的一部分運作的時候，它被稱為單元測試。

很多開發人員並不知道該怎麼提高這方面的能力，這需要培訓和教育。而且這是一個學習和積累的過程，不要想著能一夜吃成個胖子。

2.驗收測試驅動開發（ATDD）

這是基於TDD單元測試之後的一個新的水平。這不但表明了驗收標準，而且還能在開發工作開始之前自動執行開發需求。在很多情況下，需要專業測試人員和客戶攜手共同參與到測試中去。

3.持續整合（CI）

這能確保新程式碼不會干擾到已經存在的程式碼。如果再加上TDD和ATDD一起建立一個自動化、可重複的的測試套件，將會大幅度提高其使用價值。

4.結對程式設計

有關於結對程式設計的爭論似乎已經偃旗息鼓了，同樣的人們實際應用的例子也越來越少。這不可謂不是一個遺憾。因為在即時的程式碼審查上，兩個腦袋總比一個管用。它也允許開發人員將注意力全部灌注到手頭的工作上——不必分心於電話、郵件、簡訊等等，因為我們的partner會搞定。

5.程式碼審查

如果沒辦法結對程式設計，那麼退而求其次，至少得進行一次程式碼審查。最好程式碼一寫好就能落實到位一個輕量級流程的程式碼審查。我們在學校裡學的那種又大又正規的流程其實並不實際——只有NASA（ 美國宇航局）這種不差錢的土豪才買得起。所以換個輕量級的流程，意味著只需20%的成本就能享受80%的相同效果。

6.靜態分析工具

以前人人都不看好所謂的靜態分析工具。現在則好了很多，雖然它們仍然並不能真正替代程式碼審查，但是其使用成本比較低。當然可能需要購買許可證，但是一旦將它們設定進系統中之後，以後每一次我們輸入程式碼，它們都會一絲不苟兢兢業業地檢查並且快速提示發現的所有錯誤。

7.編碼標準

老實說我並不怎麼喜歡編碼標準。從我的經驗來看，很多團隊在討論編碼標準上面浪費了太多的時間，而且一旦確定了某種標準，這往往會損害一部分開發人員的利益。不過如果我們能克服這些問題，那麼絕對會有意想不到的效果。

首先建立一個討論小組——應該以一種面對面的形式，不要通過電子郵件和電話——討論出編碼標準裡應該包含哪些內容。找到需要討論的地方，規分為不同的類別：少許定位為必選專案，推薦專案的數量可以較前者多點，候選專案則可以更多。在候選組裡的需要經過深思熟慮之後才能放到推薦組和必選組中。剩下的第四組則是明確不能成為程式設計標準的內容。

每隔三至四個月檢查一下這些標準，看看有沒有需要從候選組提升到推薦組，或者從推薦組放到必選組的，要是發現什麼已經不適應當前工作的專案，那就儘快刪除或者降級。

此外，我們不應該將編碼標準當做程式碼審查的一部分，而是兩手都要抓，兩手都要硬，萬一不得不遺漏其中之一，可以藉助自動化工具，例如執行靜態分析工具，自動執行程式碼標準來檢查程式碼。

8.自動化

其實就目前而言，我們提出的大多數意見和建議，是能夠自動化執行而且也應該被自動化執行的，但是可惜的是這個概念還沒有深入人心。從長遠看，非自動化就意味著需要耗費大量的時間，而且成本更高。雖然自動化看似在短期內需要投入大量的成本，但是從整體上而言，其實是節約了成本的。

9.重構（以及重構工具）

重構的目的就在於提高程式碼質量，當然更重要的是，改善整體的設計。如果重構之後不能達到上述目的，那麼說明你的思路錯了。我們可以在重構的時候摒棄自動化單元測試，而且很多人也是這麼做的，但是這等同於高空走鋼絲的時候下面沒有安全防護網——一旦失足便萬劫不復。如果是裝備了“安全防護網”的重構不但毋須佔用大量時間，而且還能頻繁執行。

以上這些對於能提高程式碼質量顯然是顯而易見的。還有一些雖然也在圖片名單上，但是並不那麼為大家所認可，不過我認為它們也值得包括進去。

10.展示和說明（早期）

也許你會奇怪這怎麼能提高程式碼質量呢，請不要懷疑，It does。因為定期展示相關潛在客戶對於軟體的要求，能促使開發人員不斷地將他們的程式碼保持在最接近釋出的狀態，這也使得開發程式更快、更細緻。

第二個原因則是能收集更多週期性的反饋，指引我們正確的方向。

最後，如果一個開發人員害怕將他的工作展現給使用者和客戶看，這是一個非常危險的訊號，最好停下來好好自我檢查一番。

11.使用者測試

使用者測試能讓我們從另一角度進行測試，以便儘早發現問題。

與第10點相同，碎片化的處理模式能提供更為細緻的步驟。無論是在工作規劃上還是在改進程式碼上面，這都給了我們一個機會，能在做每一個決定之前都可以重新調整和矯正航向。

12.團隊凝聚力

關於團隊的凝聚力其重要性不言而喻，因為一個團隊一旦失去了凝聚力，那麼大家就會各執己見，各施其力。要想不如此，我們就必須要在開發目標和如何設計程式碼以及如何改進程式碼上面的觀點達成一致。

上述12點可能並不詳盡，歡迎大家群策群力，提出寶貴的意見和建議，謝謝。