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

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

經驗1：提前設計

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

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

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

經驗2：類與函數準則

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

· 使類與函數盡可能地小

· 類與函數應遵循單一職責原則

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

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

經驗3：使用設計模式

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

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

經驗4：代碼規范

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

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

制定好規范清單后，就堅持照做吧！

經驗5：編寫單元測試

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

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

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

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

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

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