作為代碼工作中至關重要的一環(huán)，代碼結構化是頗具難度的。要想寫出結構良好的代碼，編寫者需要具有正確的思維方式，對設計模式有自己的理解，還得擁有豐富經驗。通常情況下，要想培養(yǎng)上述能力，你要走的路可不少。

代碼結構化的重要性不應被低估，從可讀性和可維護性的角度來看，代碼結構非常重要。

經驗1：提前設計

在著手編寫代碼之前，你最好考慮一下對將要構建的應用程序進行提前設計，統(tǒng)一建模圖表(UML diagrams)就是個不錯的選擇。在編寫代碼之前，如果提前有計劃在手，編寫者可以更加專注。通過提前思考代碼的結構，創(chuàng)建一些有用的UML圖表，許多明顯缺陷都可以提前避免。

更重要的是，制定計劃能讓我們認識到，在編寫代碼前還有許多需要編寫者思考的事情。UML圖還可以防止代碼編寫者“思想游離”，并且防止編寫者在代碼里添加自認為將來會派上用場的非必要功能。

不做計劃就急著開始，在最初你能跑得快一點兒，但跳過這個步驟最終會使你不得不對大量代碼進行重構，進而消耗大量時間和動力。記住，欲速則不達。

經驗2：類與函數(shù)準則

以下準則可以幫助你保持類與函數(shù)的可讀性及可維護性：

使類與函數(shù)盡可能地小、類與函數(shù)應遵循單一職責原則

保證類與函數(shù)盡可能小可以使代碼更容易理解。一般來說，較大的類和函數(shù)應被分解為較小的專門化類別。

遵循單一責任原則可以幫助你保持類和函數(shù)在較小的級別，即每個類、每個函數(shù)只做一件事。但注意，要在合理范圍內劃分得“小”，因為多數(shù)情況下，過多的細小分類反而要比幾個大類糟糕得多。把函數(shù)分成“獲取、處理及存儲數(shù)據(jù)”這樣的大型函數(shù)是行不通的。你必須將此函數(shù)分成三個較小的函數(shù)：分別用于提取、處理和數(shù)據(jù)存儲。

經驗3：使用設計模式

了解設計模式及其工作方式可以幫助你編寫出更加結構化、更具可讀性與可維護性的代碼。如果你清楚在哪些情況下可以使用哪種設計模式，就不必非得自己想解決辦法了，你只需遵循設計原則就可以保持代碼的整潔。

不過要注意，不要過度使用設計模式，這是使用這種方法時最常見的陷阱。盡管在特定情況下可以使用設計模式，但過度使用設計模式對編寫者來說有弊無利，它會使應用過度機械化，其他開發(fā)人員會很難理解代碼。

經驗4：代碼規(guī)范

代碼結構化在很大程度上與代碼規(guī)范有關。對于每個項目來說，代碼規(guī)范都是必要，如果沒有代碼規(guī)范，代碼變得團團亂以至難以閱讀是遲早的事。

我們可以列出代碼規(guī)范清單，記錄下聲明變量的方法、命名規(guī)范等。你可以無限向列表中添加規(guī)則，規(guī)則的數(shù)量也是可以變化的，只列出對你和對你的團隊有幫助的規(guī)則便可。團隊成員也可以隨時向規(guī)范列表中添加或移除規(guī)則。

制定好規(guī)范清單后，就堅持照做吧!

經驗5：編寫單元測試

編寫單元測試能產生不錯的預期外的效果，它讓你必須對代碼進行結構化處理。為了能夠編寫出單元測試，至少要保證代碼的結構是正確的。

也許你以前聽說過或者編寫過不可測試代碼，如果有哪段代碼讓你不知道該如何編寫單元測試的話，可能是因為這段代碼功能過多，或者寫得太差。

不管是上述兩種情況的哪一種，只有一個原因會導致代碼無法測試，那就是糟糕的結構。遇到不可測試的代碼時，你會發(fā)現(xiàn)自己大部分時間都用在了重構上。單元測試便可以作為一種限制，使你必須將代碼進行結構化處理。

實現(xiàn)代碼結構化有好些方式。在你鍵入第一個代碼字母之前就開始了，包括提前考慮應用程序的設計、創(chuàng)建幫助編寫者消除明顯缺陷的UML圖等。

只要你準備編寫代碼，就應該確保擁有一份可以遵守的代碼規(guī)范表。學習使用設計模式也可以進一步幫你實現(xiàn)這個目標。同時，你還需保持類與函數(shù)單位較小，并且讓這些類與函數(shù)只做一件事。最后，要養(yǎng)成編寫單元測試的習慣，不這樣做最終只會得到一堆不可測試的代碼。

要更認真地對待代碼結構化了!