因此，言歸正傳，讓我們來看看 Clean Code 提供的最佳技巧！我們將瀏覽每一章，總結鮑伯叔叔和他的合著者所提出的想法。
第 1 章：整潔的程式碼
-
雜亂的總量隨著時間的推移而增加。
-
從頭開始恢復過時的系統非常困難。重構和漸進式改進將是最好的選擇。
-
在混亂的程式碼庫中，原本只需要幾個小時的任務可能需要幾天或幾週才能完成。
-
花時間快速行動。
-
乾淨的程式碼可以很好地完成一件事。糟糕的程式碼試圖做太多事情。
-
乾淨的程式碼經過了良好的測試。
-
當閱讀編寫良好的程式碼時，每個函數都大致符合您的預期。
-
如果您不同意具有多年經驗的人教授的原則，您至少應該在忽略之前考慮他們的觀點。
-
程式碼的讀取次數遠多於編寫次數。
-
更容易閱讀的程式碼也更容易更改。
-
讓程式碼庫比你發現它時更好（童子軍規則）。
第 2 章：名字的意義
-
仔細選擇變數名稱。
-
選擇好名字是很困難的。
-
變數或函數的名稱應表明它是什麼以及如何使用它。
-
避免使用單字元變數名稱，常用名稱除外，例如循環中的計數器變數 i。
-
避免在變數名中使用縮寫。
-
變數名稱應該是可發音的，以便您可以談論它們並大聲說出來。
-
使用易於尋找的變數名稱。
-
類別和物件必須具有名詞形式的名稱。
-
方法和函數名稱必須是動詞或動名詞對。
第 3 章：函數
-
函數應該很小。
-
該函數必須執行一項操作。
-
函數必須有描述性名稱。
-
提取 if/else 主體中的程式碼或將語句轉換為明確命名的函數。
-
限制函數接受的參數數量。
-
如果函數需要許多組態參數，請考慮將它們組合成單一組態選項變數。
-
函數必須是純函數，這意味著它們沒有副作用，並且不會修改其輸入參數。
-
函數必須是命令或查詢，但不能同時是命令或查詢（命令查詢分離）。
-
從程式碼中刪除錯誤和異常比在程式碼中保留錯誤更好。
-
將重複的程式碼提取到明確命名的函數中（不要重複自己）。
-
單元測試使重構變得更加容易。
第 4 章：評論
-
評論可能不正確。它們可能一開始就是錯誤的，或者它們最初可能是準確的，但隨著程式碼的變化，它們會隨著時間的推移而變得過時。
-
使用註釋來描述為什麼要這樣寫，而不是解釋正在發生的事情。
-
透過使用明確命名的變數並將程式碼段提取到明確命名的函數中，通常可以避免註解。
-
使用一致的前綴為 TODO 註解添加前綴，以便更容易找到。定期查看並清理您的 TODO 評論。
-
不要僅僅為了使用 Javadoc 而使用它們。描述一個方法的作用、它接受什麼參數以及它返回什麼的註釋往好了說是多餘的，往壞了說是誤導性的。
-
評論應包括讀者所需的所有相關資訊和上下文。寫評論的時候不要偷懶。
-
由於版本控制和 gitblame，不需要日誌註釋和文件作者註釋。
-
不要註解掉死程式碼。刪除它即可。如果您認為將來需要程式碼，這就是版本控制的用途。
第 5 章：格式化
-
作為一個團隊，選擇一組用於格式化程式碼的規則，然後一致地套用這些規則。無論您同意什麼規則，都需要達成協議。
-
使用自動程式碼格式化和程式碼分析器。不要依賴人們手動尋找並修復每個格式錯誤。在審查程式碼時，這是低效、低效且浪費時間的。
-
在程式碼行之間添加垂直空格，以在視覺上分隔相關的程式碼區塊。您所需要的只是在群組之間創建一條新線。
-
小文件比大文件更容易閱讀、理解和移動。
-
變數應該在使用它們的地方附近聲明。對於小型函數，這通常位於函數的頂部。
-
即使對於簡短的函數或 if 語句，仍然要正確格式化它們，而不是將它們寫在一行上。
第 6 章：物件與資料結構
-
物件中的實作細節必須隱藏在物件的介面後面。透過提供一個供物件的使用者使用的接口，您可以更輕鬆地在以後重構實現細節，而不會造成重大更改。抽象化使重構變得更加容易。
-
任何給定的程式碼片段都不應該了解它所操作的物件的內部結構。
-
使用物件時，您應該要求它執行命令或查詢，而不是詢問它的內部結構。
第 7 章：糾正錯誤
-
錯誤處理不應幹擾模組中的其餘程式碼。
-
從程式碼中刪除錯誤和異常比在程式碼中保留錯誤更好。
-
編寫帶有錯誤的測試，以確保您的程式碼能夠識別它們並且不會錯過它們。
-
錯誤訊息應該提供信息，包含有效排除故障可能需要的所有必要上下文。
-
將第三方 API 包裝在薄薄的抽象層中，使得將來更容易用一個函式庫取代另一個函式庫。
-
將第三方 API 包裝在薄薄的抽象層中可以更輕鬆地在測試期間模擬庫。
-
使用特殊情況模式或空物件模式來處理異常行為，例如當某些資料不存在時。
第 8 章：邊界
-
第三方函式庫可讓您外包各種任務，從而幫助加快產品交付速度。
-
編寫測試以確保您正確使用第三方程式庫。
-
使用適配器模式來彌合第三方庫的 API 和您想要的 API 之間的差距。
-
將第三方 API 包裝在薄薄的抽象層中，使得將來更容易用一個函式庫取代另一個函式庫。（重複第 7 章）
-
將第三方 API 包裝在薄薄的抽象層中可以更輕鬆地在測試期間模擬庫。（重複第 7 章）
-
盡量不要告訴您的應用程式太多有關任何第三方程式庫的詳細資訊。
-
依賴你能控制的東西比依賴你無法控制的東西更好。
第 9 章：單元測試
-
測試程式碼應該與生產程式碼一樣乾淨（有一些例外，通常與記憶體或效率有關）。
-
當生產程式碼發生變化時，測試程式碼也會發生變化。
-
測試有助於保持生產程式碼的靈活性和可維護性。
-
測試可讓您進行更改，讓您可以自信地進行重構，而不必擔心自己沒有註意到。
-
使用排列-執行-斷言（也稱為構建-操作-檢查、設定-練習-驗證或給定-何時-然後）模式建立測試。
-
使用特定於領域的函數使測試更易於編寫和閱讀。
-
每次測驗給一個概念評分。
-
測試必須快。
-
測試必須是獨立的。
-
測試必須是可重複的。
-
測試不應需要確認。
-
測試應該及時編寫，在編寫生產程式碼之前或之後不久，而不是幾個月後。
-
如果您的測試很糟糕，那麼您的程式碼中可能會存在錯誤。
第10章：課程
-
班級規模應該很小。
-
類別應該只負責一件事，並且應該只有一個改變的原因（單一責任原則）。
-
如果您無法為類別起一個清晰的名稱，那麼它可能太大了。
-
當你讓一段程式碼可以運作時，你的工作並沒有結束。下一步將是重構和清理程式碼。
-
在應用程式中使用許多小類而不是幾個大類可以減少開發人員在處理任何給定任務時必須理解的資訊量。
-
擁有一個好的測試套件可以讓您在將大類分解為更小的類別時充滿信心地進行重構。
-
類別應該對擴展開放，但對修改封閉（開閉原則）。
-
介面和抽象類別創建了接縫，使測試變得更加容易。
第11章：系統
-
使用依賴注入使開發人員能夠靈活地將具有適當介面的任何物件傳遞給另一個類別。
-
使用依賴項注入在應用程式中的物件之間建立接口，以使測試更容易。
-
軟體系統不像建築物，需要事先設計。它們更像是隨著時間的推移而發展和擴張的城市，以適應當前的需求。
-
推遲到最後關鍵時刻才做出決定。
-
使用特定於領域的語言，以便領域專家和開發人員使用相同的術語。
-
不要使您的系統過於複雜。使用最簡單有效的方法。
第12章：部署
-
無法測試的系統無法驗證，無法驗證的系統永遠不應該部署。
-
編寫測試可以帶來更好的設計，因為易於測試的程式碼通常使用依賴項注入、介面和抽象。
-
一組好的測試將消除重構時破壞應用程式的恐懼。
-
重複程式碼會帶來更多風險，因為程式碼中有更多地方可以更改，甚至更多地方可以隱藏錯誤。
-
你現在寫的程式碼更容易理解，因為你深入地理解它。其他人想要快速達到同樣的理解程度並不容易。
-
軟體專案的大部分成本與長期維護有關。
-
測試充當應用程式應該（以及確實）如何表現的活生生的文檔。
-
一旦您的程式碼有效，就不要再進行任何操作。花點時間讓它變得更清晰、更容易理解。
-
在不久的將來，下一個閱讀您程式碼的人很可能就是您。透過編寫易於理解的程式碼來善待未來的自己。
-
抵制教條。擁抱實用主義。
-
成為一名真正優秀的軟體工程師需要幾十年的時間。您可以透過向周圍的專家學習並學習常用的設計模式來加快學習速度。
第13章：並行性
-
編寫並行程式碼很困難。
-
偶爾出現的難以重現的錯誤和問題通常是並發問題。
-
測試並不能保證您的應用程式沒有錯誤，但可以最大限度地降低風險。
-
了解常見的並發問題及其可能的解決方案。
第14章：順序細化
-
乾淨的程式碼通常不是從一張白紙開始的。您首先編寫一個粗略的解決方案，然後重構它以使其更清晰。
-
一旦程式碼開始工作就停止工作是錯誤的。在它已經發揮作用後，花點時間讓它變得更好。
-
騷亂正在逐漸加劇。
-
如果您發現自己陷入添加功能太困難或花費太長時間的困境，請停止編寫功能並開始重構。
-
增量變化通常比從頭開始重建更好。
-
使用測試驅動開發 (TDD) 進行大量非常小的變更。
-
好的軟體設計包括分離程式碼中的關注點並將程式碼分成更小的模組、類別和檔案。
-
弄亂後立即清理比稍後清理更容易。
第 15 章：JUnit 內部結構
-
負變數名稱或條件式比正變數名稱或條件式更難理解。
-
重構是一個充滿嘗試和錯誤的迭代過程。
-
讓程式碼庫比你發現它時更好（童子軍規則）。（從第 1 章重複）
第 16 章：重構 SerialDate
-
程式碼審查和對程式碼的批評使我們變得更好，我們應該對此表示歡迎。
-
首先讓程式碼工作，然後修復它。
-
並非每一行程式碼都需要測試。
第17章：氣味與啟發法
-
乾淨的程式碼不是一套規則，而是決定你工作品質的價值體系。
GO TO FULL VERSION