編寫高質量代碼，從「心」做起！

前言

編寫高質量代碼是程序猿（媛）對自身的基本要求，從開始code的第一天起，我們都希望自己的代碼能夠被別人讚賞。如何才能編寫出高質量代碼呢？筆者最近參加一次相關培訓，小有感觸，將所學內容總結後與大家分享。

從一個開發團隊的交付故事說起

有這樣一個開產品開發團隊，他們正在研發一個新軟體項目，客戶希望能夠在6個月後上線交付第一版本，之後每隔二個月推出一個包含了新功能的迭代版本。開發團隊接到任務後，立即全負荷的投入到軟體開發工作中：

項目啟動了~~~~

......................................

6個月後：產品v1.0順利投產，業務模塊1順利交付使用

......................................

8個月後：產品v1.1成功投產，業務模塊2交付使用

......................................

10個月後：由於投產後客戶發現軟體缺陷，產品v1.2在開發新功能同時還要修復原有的缺陷，產品模塊3未按期交付

11個月後：經歷了3個月的研發期，產品v1.2終於投產了，產品模塊3交付使用。同時客戶的新功能需求接踵而至，同時還反饋了一些已有功能的缺陷

這時，開發負責人對產品經理說：「我們真的不能再增加新功能了，我們需要停下來重寫代碼，代碼庫一團糟，就像紙糊的老虎，根本應付不了持續增加的用戶，並且最近原開發團隊人員的頻頻離開，新開發人員接手原有代碼非常困難」。

產品經理苦惱中...........

從上述案例中，我們發現軟體產品的交付過程往往會遇到一個問題：產品交付的周期逐漸增長，直至最後代碼不得已重構甚至重寫；同時開發團隊的系統維護和擴展壓力不斷增大。這時，我們不得不認真的反思一下軟體系統代碼到底該是什麼樣的代碼了 。

代碼是寫給誰的？

有很多人認為，代碼是寫給機器的，是用於指揮機器幹活的一組指令而已，因此只要功能實現了，越精鍊越能顯示程序員的水平。真的如此嗎？ 看看計算機大師的看法吧。

隨著年齡的增長，我逐漸意識到編程不僅僅是讓程序運行而已，編程是創造一個易於理解的、可以維護的、高效的作品。

——Google公司首席JAVA架構師 Joshua Bloch

讓我們改變傳統的對待編程的態度，不是把我們的主要任務想像成是去指示計算機要做什麼，而是關注於向人們解釋我們希望計算機做什麼。

—— Donald Knuth

現在的軟體系統複雜度越來越大，軟體代碼很少是由一人獨立開發完成，因此，代碼寫出來後一定要考慮可讀性，因為它最終是寫給人們看的，如文章具有清晰明了的邏輯思路和簡單易懂的文字描述一樣，代碼也應該便於閱讀、易於理解。編程的核心價值是：溝通，簡單，靈活。這就要求我們用心去寫代碼，去寫極致簡單的代碼，寫層次清晰的代碼，寫易於擴展的代碼，寫人人都能理解的代碼。

什麼是好代碼？

「Good code is not bad code」，如果希望寫出好的代碼，首先要識別出來代碼的壞味道。壞味道有很多種，其中代碼複雜度高是主要的壞味道之一。因此，好代碼首先複雜度不高。

針對於函數而言，可以採用下面的十個一的原則來降低它的複雜度：

1、每個變數只用於單一用途

2、每行代碼只表達一件事情

3、一個循環只做一件事

4、一個表達式只做一件事

5、每個函數語句應該遵循單一職責原則

5、一種變化的修改應該僅僅修改一次

6、代碼組織的一次只做一件事情

7、函數應該遵守單一指責

8、圈複雜度小於一十

9、函數第一原則：短小

10、編寫函數應該保持一心一意

針對於複雜表達式，降低複雜度的方法有：

1、去掉"非「

2、編寫肯定形式的表達式

3、拆分複雜表達式

4、用有意義的變數代替表達式

5、用函數代替複雜表達式，對複雜表達式進行隔離

6、用表驅動法重構優化複雜表達式。

好代碼一定是整潔的代碼，整潔的代碼簡單直接，不隱藏設計者的意圖，充滿了乾淨利落的抽象和直截了當的控制語句。有人會認為，追求規範格式的代碼，性能不一定好。但是實驗證明：清晰簡潔的代碼是性能高的代碼，即使不高也便於優化。

編寫高效代碼的基本原則

編寫好代碼，高效代碼需要對代碼保持「謙卑」的心態，在編碼過程中需要牢記一些基本原則：

1、單一抽象層次原則

2、單一職責原則：每個類，每個函數，每個循環只做自己最擅長的事，且只做這件事

3、信息隱藏原則：隱藏變化的內容，將具有相同變化率的數據放在一起

4、隔離變化源：將容易變化的部分進行封裝提取成函數

5、去掉重複代碼原則：如果發現有兩塊或以上代碼重複，考慮提取函數

6、定義有意義的變數和函數名：清晰的函數名，變數名看起來簡單易懂，無需注釋

7、非侵入原則：修改別人的代碼時，盡量保持起碼的道德，盡量不要破壞原來代碼的體系結構

8、依賴倒置原則：要針對介面編程，具體依賴抽象，編寫的代碼要考慮可擴展性

9、開閉原則：高效的代碼都符合開閉原則，對擴展開放，對修改關閉。

10、程序短小原則：短小精鍊的代碼高效清晰易維護。拖沓冗長的代碼難於維護

如何修改遺留系統代碼

回顧一下文章開頭的那個團隊的系統代碼會變爛？應該跟開發過程中程序員的一些壞習慣是密不可分的，如接到需求後，開發人員直接往現有的模塊、對象、函數和方法裡面硬塞代碼邏輯，就會導致添加了幾個功能模塊後，整個代碼就面目全非了，產生了所謂的代碼纏繞，後續功能擴展就非常困難。

軟體業界有句經典語言是：你擁有的代碼越多，維護和添加新內容所付出的成本的就越高。

對於遺留系統的代碼，尤其是業務邏輯複雜，功能模塊相互交織的系統代碼，我們更要保持「謙卑」的心態，修改任何一行代碼都加倍小心。因此，我們在改造老系統代碼的時候，首先要做到老代碼與新代碼的隔離，完成不動原代碼的隔離。

編程是一種態度，編程是一種技藝，編程是一種習慣。作為一名程序員，首先我們需要對於自己的代碼保持一個謹慎負責的態度，時刻牢記「代碼是一種債務」，不斷提升自我的編寫高質量代碼的技藝，養成識別爛代碼，編寫極致簡單、層次清晰的代碼，對於代碼不斷推敲和重構的好習慣，定能得到同行的敬佩和軟體用戶的讚美。

蘋果用戶讚賞專用二維碼

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！