代碼質量的三點我的體會

Martin Fowler在他的著做《重構，改善既有代碼的設計》的第一章說過「任何一個傻瓜都能寫出計算機能夠理解的代碼。惟有寫出人類容易理解的代碼，纔是優秀的程序員。」
   Kent Beck也這麼形容過本身「我不是個偉大的程序員，我只是個有一些優秀習慣的好程序員。」
   本身從本科階段到如今也大概寫了三年多代碼了，再加上7個月的實習和3個多月的工做時間，也慢慢體會到編程不易，而要寫出高可讀性和少缺陷的代碼更不易。
   雖然說「軟件工程沒有銀彈」，但也有一些方法能夠予以彌補。方法即Kent Beck所說的培養一些優秀的編程習慣。
   我我的寫一些代碼時總覺得代碼很簡單，功能邏輯都很簡單，因此老是所有寫完，而後再跑，但90%的狀況跑的結果都讓我失望。一次次打擊以後讓我開始的信心滿滿逐漸無存，本身也開始嘗試理性思考如何編程才能保證效率同時提升代碼質量（代碼可讀性強、缺陷率低...）。
   如下是個人三點我的體會：
   第一點：Code Review，並且注意是在每寫完一段代碼就立刻Review。
   好比一個方法就十幾行代碼那麼能夠寫完這個方法而後Review，Review時審查代碼分支，至關於人腦編譯運行。而若是一個方法很長，那麼能夠將方法拆成幾塊，每寫完一塊Review一下。這樣能規避不少咱們看來比較弱智的錯誤。好比我在編寫返回布爾值的代碼時常常先讓返回值直接爲false。以下：

public boolean test() {   // TODO
   return false;
}

   而後繼續完成TODO部分代碼：

public boolean test() {   // 一大段處理邏輯
   return false;
}

   這樣寫完以後我立刻在其餘地方調用test()，但發現test方法始終返回false。我百思不得其解，只好單步調試，才發現我犯了一個很弱智的問題，你懂的。而若是我寫完這個代碼後不急着運行程序，而是先靜態Review下代碼，這種低級錯誤是徹底能夠避免的。   
   第二點：重構，並且是持續重構。
   一直以來我只是人云亦云地認爲重構對提升代碼質量頗有幫助，但實際上一直對重構沒有什麼概念，也一直沒有在實際編碼中真正踐行過多少。但我試着真正動手去重構了兩個例子後，才發現重構確實威力強大，它能夠提升代碼可讀性，並加深你對代碼業務邏輯的理解，也所以減小了引入Bug的機率。重構只要使用得當，還能夠在代碼簡潔性和代碼可讀性之間取得不錯的平衡，具體例子請參考：
   編程基礎問題探討：代碼可讀性與代碼簡潔性的權衡 http://www.oschina.net/code/snippet_111708_15532
   編程基礎問題探討：雙重循環寫法 http://www.oschina.net/code/snippet_111708_15531

   第三點：測試驅動。
   有時候我從前臺頁面到後臺業務處理，寫完幾百行代碼而後運行，出了點小問題，而後單步追蹤，Fix掉。再跑，沒問題，OK發佈，提測。而後測試一測，各類問題連續不斷地又回到我手裏。想了好久，最後發現測試驅動應該是避免我這種困境的較好方法了。按照我以前的「撞大運」式編程，我只能保證某一個或有限的幾個流程（或分支）運行正確，實際上代碼中仍是可能存在很多「定時炸彈」。而藉助測試驅動開發方法，我能夠每寫一塊就測試一塊，確保每一塊都是正確的，這樣以後再集成測試顯然能好很多。並且要知道Fix Bug的時間常常比寫代碼的時間要多不少，尤爲是在系統運行很長一段時間後才發現Bug（這時已經對系統不是那麼熟悉了）或由非代碼第一做者Fix Bug時表現更爲明顯。

   常見的單元測試工具包括針對Java的JUnit，針對C#的NUnit和VS 2010以上版本自帶的Unit Testing工具。