全文共1696字，預計學習時長6分鐘
圖源：unsplash
作爲代碼工作中至關重要的一環，代碼結構化是頗具難度的。要想寫出結構良好的代碼，編寫者需要具有正確的思維方式，對設計模式有自己的理解，還得擁有豐富經驗。通常情況下，要想培養上述能力，你要走的路可不少。
代碼結構化的重要性不應被低估，從可讀性和可維護性的角度來看，代碼結構非常重要。
經驗1：提前設計
在着手編寫代碼之前，你最好考慮一下對將要構建的應用程序進行提前設計，統一建模圖表（UML diagrams）就是個不錯的選擇。在編寫代碼之前，如果提前有計劃在手，編寫者可以更加專注。通過提前思考代碼的結構，創建一些有用的UML圖表，許多明顯缺陷都可以提前避免。
更重要的是，制定計劃能讓我們認識到，在編寫代碼前還有許多需要編寫者思考的事情。UML圖還可以防止代碼編寫者“思想遊離”，並且防止編寫者在代碼裏添加自認爲將來會派上用場的非必要功能。
不做計劃就急着開始，在最初你能跑得快一點兒，但跳過這個步驟最終會使你不得不對大量代碼進行重構，進而消耗大量時間和動力。記住，欲速則不達。
經驗2：類與函數準則
以下準則可以幫助你保持類與函數的可讀性及可維護性：
· 使類與函數儘可能地小
· 類與函數應遵循單一職責原則
保證類與函數儘可能小可以使代碼更容易理解。一般來說，較大的類和函數應被分解爲較小的專門化類別。
遵循單一責任原則可以幫助你保持類和函數在較小的級別，即每個類、每個函數只做一件事。但注意，要在合理範圍內劃分得“小”，因爲多數情況下，過多的細小分類反而要比幾個大類糟糕得多。把函數分成“獲取、處理及存儲數據”這樣的大型函數是行不通的。你必須將此函數分成三個較小的函數：分別用於提取、處理和數據存儲。
經驗3：使用設計模式
圖源：unsplash
瞭解設計模式及其工作方式可以幫助你編寫出更加結構化、更具可讀性與可維護性的代碼。如果你清楚在哪些情況下可以使用哪種設計模式，就不必非得自己想解決辦法了，你只需遵循設計原則就可以保持代碼的整潔。
不過要注意，不要過度使用設計模式，這是使用這種方法時最常見的陷阱。儘管在特定情況下可以使用設計模式，但過度使用設計模式對編寫者來說有弊無利，它會使應用過度機械化，其他開發人員會很難理解代碼。
經驗4：代碼規範
代碼結構化在很大程度上與代碼規範有關。對於每個項目來說，代碼規範都是必要，如果沒有代碼規範，代碼變得團團亂以至難以閱讀是遲早的事。
我們可以列出代碼規範清單，記錄下聲明變量的方法、命名規範等。你可以無限向列表中添加規則，規則的數量也是可以變化的，只列出對你和對你的團隊有幫助的規則便可。團隊成員也可以隨時向規範列表中添加或移除規則。
制定好規範清單後，就堅持照做吧！
經驗5：編寫單元測試
編寫單元測試能產生不錯的預期外的效果，它讓你必須對代碼進行結構化處理。爲了能夠編寫出單元測試，至少要保證代碼的結構是正確的。
也許你以前聽說過或者編寫過不可測試代碼，如果有哪段代碼讓你不知道該如何編寫單元測試的話，可能是因爲這段代碼功能過多，或者寫得太差。
不管是上述兩種情況的哪一種，只有一個原因會導致代碼無法測試，那就是糟糕的結構。遇到不可測試的代碼時，你會發現自己大部分時間都用在了重構上。單元測試便可以作爲一種限制，使你必須將代碼進行結構化處理。
圖源：unsplash
實現代碼結構化有好些方式。在你鍵入第一個代碼字母之前就開始了，包括提前考慮應用程序的設計、創建幫助編寫者消除明顯缺陷的UML圖等。
只要你準備編寫代碼，就應該確保擁有一份可以遵守的代碼規範表。學習使用設計模式也可以進一步幫你實現這個目標。同時，你還需保持類與函數單位較小，並且讓這些類與函數只做一件事。最後，要養成編寫單元測試的習慣，不這樣做最終只會得到一堆不可測試的代碼。
要更認真地對待代碼結構化了！
一起分享AI學習與發展的乾貨
歡迎關注全平臺AI垂類自媒體 “讀芯術”
（添加小編微信：dxsxbb，加入讀者圈，一起討論最新鮮的人工智能科技哦～）