你好，我是猿java。

作為一名 Java程序員，如果把代碼比作孩子，代碼質量就如同孩子的健康，因此，作為技術人員，日常工作勢必堅守兩條紅線：

• 保證代碼交付質量
• 保證代碼交付時間

對于這兩條紅線，其實不難理解，總結成一句話：在規定的時間內交付高質量的代碼。

那么，什么是高質量的代碼？如何才能寫出高質量的代碼？為什么有的程序員工作 5年，寫出來的代碼質量還不如 3年的程序員？今天我們就來聊一聊。

一、什么是高質量代碼

代碼的“好”與“壞”是一個相對的描述，因此，高質量代碼也是一個很寬泛的概念，很難給它下一個精準的定義，但是，我們可以結合日常的開發工作經驗，給出幾個常見的衡量維度：

1. 可讀性

高質量的代碼首先需要具備可讀性，我們編寫的代碼除了需要讓機器能編譯運行之外，更需要讓程序員讀懂，因為只有程序員讀懂了它，才能更好地修 bug，添加新功能，做后期維護等等。

可能有小伙伴會說，Spring的源碼很難讀懂，因此它不具備可讀性，這種理解是錯誤的，Spring框架是 Java生態中比較優秀的開源代碼，讀不懂是因為“內功”不夠，本文的可讀性是指代碼命名是否規范，注釋是否合理，分層是否清晰以及是否具備高內聚低耦合等特性。

2. 可維護性

現實工作中，很難遇見一次性代碼（開發部署完之后再也不需要迭代），大部分情況都需要在一個模塊上不斷地迭代新功能和新代碼，因此，高質量的代碼必須具備可維護性。

可維護性反饋到代碼上，可以通俗地表達成：bug能修改，老代碼改得動，新功能可添加。而這些更改花費的代價就體現了可維護的難和易，比如：改動是否會增加大量的新 bug，改動對現有的邏輯的破壞性有多大，或者說改動的時間是否會很長。

3. 可擴展性

在代碼設計 SOLID 中有一個很重要的原則就是開閉原則，要求代碼需要 “對修改關閉，對擴展開放”，因此，高質量的代碼需要具備可擴展性。在應對業務迭代時，開發者需要多關注代碼能否用最小的改動來適配新的功能。

4. 可復用性

在日常開發中，盡量不重復造輪子，具體到代碼上，不應該出現大量重復的代碼，代碼應該保持簡潔，重復的代碼可以抽離出來，實現代碼復用。因此，可復用性也是衡量高質量代碼的一個重要標準。

5. 可測試性

單測是開發人員保證代碼質量的一個重要方法，因此，編寫的代碼是否具備可測試性，也是衡量代碼高質量的一個標準。如果編寫的代碼很難寫單元測試，那是否意味著代碼設計存在很大的問題？

在分析了高質量代碼的幾個常用衡量維度之后，我們可以總結：所謂高質量的代碼，其實就是衡量能否寫出可讀性好，易維護，易擴展，復用性高，可測試的代碼。

接下來提供十種高效提升代碼質量的方法。

二、提升代碼質量方法

1. 規范命名

眾所周知，一個好的名字可以使人受用一生，對于代碼也是如此，好的命名可以幫助讀者更好地理解代碼的功能。

對于計算機科班出身的小伙伴，或許在大學的第一節編程課就被強調：代碼命名要簡明扼要并且見名知意，不要使用拼音，不要使用非公認的縮寫等等，下面為代碼命名的幾點建議：

(1) 使用常見的英文單詞，不使用拼音

代碼的命名，應該盡量使用常見的英文單詞，這樣對于大部分人來說能夠知道其意圖。不要使用拼音命名，在軟件開發領域，英文是主要的編程語言和命名規范。使用拼音給代碼命名違反了行業的慣例和標準而且可讀性差。

(2) 使用公認的縮寫，否則使用全稱

有時候，為了簡化命名，會使用縮寫，但是這些縮寫一定要是業內大家公認的，比如：Impl 指代 Implement， str 指代 String，num 指代 number，del 指代 delete。

(3) 使用和團隊一致的命名風格

現在的開發大部分是團隊合作，因此，代碼命名應該在團隊內部保持一致，比如：和數據庫交互的 Reporitory層，一般都是 CRUD方法的封裝，如果團隊使用 selectXXX 代表查詢，我們就不要使用getXXX 或者 queryXXX，這樣檢索查詢的方法時，可以根據select定位，同理，對于添加數據是使用 addXXX 還是 saveXXX 或者 insertXXX，也需要保持一種方式。

(4) 命名不要太長

命名要盡量的簡短，而且能準確的傳達意思，如果需要使用長命名，建議不要超過5個單詞。

溫馨建議：如果你在日常工作中對于命名拿不準時，可以給身邊的同事參考，看看他們對該命名是否和你的本意是一致，這樣也能幫助你更好的去命名。

2. 巧用注釋

命名可以幫助讀者從字面上了解代碼的功能，但無法傳達代碼更多細節，因此，需要借助注釋來完成這部分功能。喜歡查看源碼的小伙伴應該可以發現，在 JDK，Spring等這些優秀的開源框架的源碼中，類，方法甚至變量，幾乎都有相應的注釋，而我們在使用某個功能時，最直接的方式往往是通過官方提供的注釋來了解其功能，因此，注釋的重要性可想而知。

因此，注釋是命名的補充和增強。

注釋需要寫什么內容呢？這里以 java.util.Collections 為例， 如下圖：

通過 JDK 的 Collections源碼注釋可以看出：注釋的內容大概包含 5部分信息：what, why, how, time, authors 即是什么？為什么？怎樣做？時間 和 作者。我們可以根據需要靈活的搭配來添加注釋。需要注意的，注釋也需要簡明扼要，盡量使用一些提煉，解釋和總結性的語句，切勿長篇大論。

3. 代碼風格

一個好的代碼風格可以讓代碼看起來很清爽，降低代碼閱讀的復雜度。代碼風格主要體現在以下幾點：左括號風格，代碼縮進，空行，超長行，魔數，方法代碼過多，方法參數過多

• 左括號風格在代碼行尾還是換行使用左括號，這個根據個人習慣，不過團隊合作要求保持一種風格。
• 代碼縮進代碼編寫時，為了美觀，一般都不會頂格，需要縮進，因此常見的縮進有 兩格縮進和四格縮進，選擇哪一種也是根據個人習慣，不過團隊合作要求保持一種風格。
• 空行在方法內部，我們可以使用空行，將邏輯獨立的代碼塊區分，這樣，一方面可以更方便的閱讀方法實現，另一方面，當獨立的代碼塊代碼量增多時，可以考慮將代碼塊抽離成新的方法。
• 超長行每行的代碼量不要太長，通常建議電腦一屏的寬度為準，如果超過一屏，建議換行。
• 魔數在代碼編寫時，不要出現魔數，我們要善于使用常量去定義這些魔數，增加代碼的可讀性。
• 方法代碼過多每個方法中的代碼量不要太多，因為代碼太多會增加方法閱讀的復雜度，通常建議電腦一屏的高度為準，超過了就要考慮能否再抽離出新方法。
• 方法參數過多編寫方法的時候，通常都會定義入參，一般建議入參的個數不要超過5個，如果再多就需要考慮封裝對象來傳遞參數。

以上代碼風格如果是團隊合作，最好是保持一致。更多代碼規范 推薦《代碼整潔之道》和《阿里巴巴開發手冊》

4. 快速短路

如下的偽代碼，當 user == null時，可以通過 return快速短路返回，去除多余的 esle 語句。因此，在日常業務開發中，遇到類似的情況，一定要做到快速短路，切莫使用大量嵌套。比如 if-esle 語句可以使用 return 快速短路；對于 for 循環可以使用 break，continue，return等提前跳出，減少不必要的遍歷；

public User getUser(String id) {
 // get by id
 User user = getById(id);

 if(user == null){
  return null;
 } else {
   // else 邏輯
 }
 
 // 優化成
 if(user == null){
   return null;
 }
 // else 邏輯

5. SOLID原則

在類或者方法的設計上要盡量遵守 SOLID原則，SOLID原則是業內一個比較的原則，關于 SOLID原則可以參考小編以往的文章：優雅代碼，從 SOLID 開始

6. 設計模式

設計模式在代碼中的使用是一個比較高階的能力體現，巧用設計模式，可以大大提高代碼的可維護性、可擴展性和可重用性等功能，在很多開源的框架上都有設計模式的體現，比如：Spring 中的單例模式（Single Pattern）工廠模式（Factory Pattern），代理模式（Proxy Pattern），適配器模式（Adapter Pattern），模板模式（Template Pattern），觀察者模式（Observer Pattern）等等。

如果你對設計模式不是很熟悉，推薦書籍 Erich Gamma 的《設計模式》，另外，JDK 和 Spring框架也是一個很好的學習資料，可以對照著源碼中設計模式的代碼，加強對設計模式的理解，然后可以嘗試著在日常開發中去使用某些設計模式。

7. 單元測試

單元測試是開發人員保證代碼質量最直接的方式，但現實工作中卻被很多人忽略，有的借故業務開發忙，沒有把時間寫單測，因此把測試功能全部丟給測試人員，有的是不如何寫單測，關于單元測試，可以參閱小編以往文章：TDD，什么是 測試驅動開發？

8. 數據結構

有人說 程序 = 數據結構 + 算法，足以看出數據結構和算法的重要性，作為 Java程序員，我們經常使用的 HashMap, List, Set, String 等都是 Java 語言對數據結構的一種友好封裝，關于數據結構，可以參閱小編以往文章：數據庫，你必須掌握的8種數據結構！ 數據結構之美：為什么 MySQL 選擇 B+樹做索引？

在實際工作中，很多人面對的工作絕大多數是業務開發，所以處理數據肯定離不開數據結構，建議平時多研究 JDK 的源碼，比如：Map，List 等常用的數據結構的底層實現原理，這樣在使用時才能得心應手應手。

9. 算法

近些年，算法在技術面試中的比重越來越大，特別是在一些知名的互聯網公司面試，如果代碼中能夠合理地使用算法，將事半功倍。需要說明的是，在日常的業務開發中，手寫算法的概率比較低，一般會使用三方框架，比如：Google Guava中的限流算法。

對于算法，似乎沒有很好的捷徑，小編的建議是：經常去算法網站上刷題，一方面讓算法能力處于隨時可以面試的狀態，一方面通過大量的算法實現量變到質變，掌握算法的精髓。

10. 重構

重構是代碼迭代中一直會存在的行為，當發現代碼有 Bad Smell “壞味道”時，得考慮代碼是否需要重構。重構，一般分為小重構和大重構，小重構通常是指工作量小，時間可控（比如時間不超過 2個工作日），甚至不需要測試參與。大重構是指時間周期比較大，對代碼的改造比較大，一般需要整體設計，然后分階段進行。關于代碼重構，可以參考微服務作者 Martinfowler 的博客：https://martinfowler.com/books/refactoring.html 或者 Martinfowler 的書籍：《重構，改善既有代碼的設計》第二版，《重構與模式》《修改代碼的藝術》

三、總結

本文分析了高質量代碼的幾個衡量維度：

• 可讀性
• 可維護性
• 可擴展性
• 可復用性
• 可測試性

在編寫代碼時，應該多關注上面幾個因素，一開始可以刻意練習，然后慢慢變成一種習慣，這樣編寫的代碼質量應該不會太差。

接著我們介紹了提升代碼質量的 10種常用方法：

• 規范命名
• 巧用注釋
• 代碼風格
• 快速短路
• 單元測試
• SOLID原則
• 設計模式
• 數據結構
• 算法
• 重構

前 4種方法更多體現在代碼的“形”上，體現了程序員對代碼細節的把握，而后 6種方法則更多體現了代碼的“神”，體現了程序員基本功和能力。

根據小編多年的工作經驗，前 4種方法是最簡單，提升代碼質量最見效的方法，它們幾乎和能力和工作年限無關，完全在于程序員能否扣住細節，如果能夠在這 4個方法上多花點功夫，編寫的代碼已經可以甩很多人一條街了。

對于后 6種方法，是開發人員內功的體現，它要求的是一個長期的積累和修煉過程，是開發人員能力差距的最好體現，所以，通過這 6點可以很好地定位某個程序員的編程段位。建議平時多閱讀一些業內大牛的經典書籍。

四、個人心得

工作中，經常會遇見一些工作 5年的程序員，寫的代碼質量卻遠不如 3年的程序員，為什么？小編覺得有以下幾個原因：

1. 職業規劃不清晰

對于他們來說，大部分都沒有清晰職業規劃，沒有方向自然就沒有努力的目標，沒有目標就很容進入日復一日循環重復工作的僵局。

2. 代碼能用就行

工作中小編也和一些人討論過，他們對代碼的態度是：沒有必要這么苛刻，能用就行。如果是剛進入社會工作，或許還能理解，如果已經工作 3年以上，還是這種想法，競爭力在哪里？作為程序員，代碼質量不就是最好的武器嗎？

3. 編程不是興趣

對于很多人來說，選擇編程并不是因為喜歡而是覺得它的工資相對其他行業來說會高一些。眾所周知，興趣是最好的老師，如果長年累月的干一件沒有興趣的事，能干好嗎？

4. 外部誘惑太多

游戲，短視頻等外部誘惑太多，一玩停不下來，工作之余的大部分時間都被這些“精神鴉片”消耗殆盡。

因為篇幅有限，不可能把每個細節點都講清楚，分享一個小編多年來一直在踐行的學習方法：持續學習，多聽，多看，catch 他人優秀的 idea，然后不斷地豐富和領會該 idea，最終形成自己的方法論。豐富和領會的過程就在不斷地強大自己，相信長年累月的積累，終有一天你也可以寫出讓人賞心悅目的高質量代碼。