代码整洁之道内容概括
第二章 有意義的命名
一、變量名的命名：
1.名副其實
變量，函數或類的名稱應該已經答復了所有的大問題。它應該告訴你，它為什么會存在，它做什么事情，應該怎么用。如果名稱需要注釋來補充，那么就不算名副其實。
2.避免誤導
必須避免留下掩藏代碼本意的錯誤線索。
3.做有意義的區分
只要體現出有意義的區分，使用a和the這樣的前綴就沒有錯。廢話就是冗余。
4.使用讀得出來的名稱
不要用傻乎乎的自造詞，而不是恰當的英語詞。
5.使用可搜索的名稱
使用便于搜索的名字。
6.避免使用編碼
把類型或者作用域編進名稱里面，徒然增加了解碼的負擔。沒理由要求每位新人都在弄清要應付的代碼之外，還要再搞懂另一種編碼”語言”。
7.避免思維映射
不應當讓讀者在腦中把你的名稱翻譯為他們熟知的名稱，尤其是在經常出現在選擇是使用問題領域術語還是解決方案領域術語的時候。
8.類名或對象名最好使用名詞或者名詞短語
9.方法名最好使用動詞或者動詞短語
10.別扮可愛
命名一定要通俗易懂。
11.每一個概念對應一個詞
給每個抽象概念選擇一個詞，并一以貫之
12.別用雙關語詞
避免將同一個詞用于不同目的，遵循一詞一義的原則
12.使用解決方案領域名
13.使用源自所涉領域名
14.添加有意義的語境
在一個bean中定義變量名的時候，變量名一定是基于實際使用場景。
15.不要添加沒用的語境
第三章 函數
1.短小
函數第一規則是要短小。第二條規則是還要更短小。
2.只做一件事
a.函數應該做一件事。做好這件事。只做一件事。如果可以從你的函數中還能拆分出一個函數，該函數不僅只是單純地重新詮釋其實現，那么你設計的函數就不是一個好的函數。
b.函數中的區段，如果函數被切分了多個區段，這就證明該函數做的事情太多了。
3.每個函數一個抽象層級
4.switch語句
確保每個switch都埋藏在較低的抽象層級，而且永遠不重復。
5.使用描述性的名稱
命名方式要保持一致。使用與模塊名一脈相承的短語、名詞和動詞給函數命名。例如：includeSetupPages。
6.函數參數
最理想的函數參數的數量是零個，其次是一，再次是二，應盡量避免三。有足夠的理由才能用上三個以上的參數。
如果函數看來需要兩個，三個或者三個以上參數，就說明其中一些參數應該封裝為類了。
函數和函數的參數命名一般是動名詞比較好。
7.無副作用
8.分割指令與查詢
函數要么做什么事，要么回答什么事，但二者不可兼得
9.使用異常替代返回錯誤碼
a.返回錯誤碼的時候，就是在要求調用者立刻處理錯誤。
b.如果使用異常替代返回錯誤碼，錯誤處理代碼就能從住路徑代碼中分離出來，得到簡化。
c.抽離try/catch代碼塊
10.別重復自己
11.結構化編程
第四章 注釋
1.如果你代碼寫的足夠好的話，可以讓人一看就懂，那么你就不需要再寫注釋。如果你的代碼需要注釋，那么你就需要想想是不是你的表達水平有問題。
2.真正好的注釋是想辦法不用寫注釋，那么什么樣的注釋需要寫呢？
a.法律信息
b.提供信息的注釋
c.提供意圖的解釋
d.闡釋
e.警告
f.TODO注釋
TODO是一種程序要認為應該要做的，但是由于某種原因沒有做的
g.放大
放大某些看似不合理的地方
第六章 對象和數據結構
1.得墨忒定律
模塊不應該了解他所操作對象的內部情形。對象隱藏數據曝露操作，這就意味著對象不應該通過存取器曝露其內部結構。
第七章 錯誤處理
1.將業務邏輯和出錯處理一定要隔離開，但是并不是所有的情況都試用，在不適用的情況下我們可以創建一個配置對象將特殊情況給予返回。
2.異常處理不能過多的曝露實現細節，主要提現在異常拋出的棧信息上。
第八章 邊界
1.整潔的邊界，邊界上的代碼要清晰的分割和定義了期望的測試。應該避免我們的代碼過多地了解第三方代碼中的特定信息。
第九章 單元測試
1.TDD 三定律
a.在編寫不能通過的單元測試前，不可編寫生產代碼。
b.只可編寫剛好無法通過的單元測試，不能編譯也算不通過
c.只可編寫剛好足以通過當前失敗測試的生產代碼
2.整潔測試三要素
a.可讀性
b.可讀性
c.可讀性
3.整潔測試的五條原則：
a.快速，測試應該夠快
b.獨立，測試應該相互獨立
c.可重復，測試應當可在任何環境中重復通過。
d.自足驗證，測試應該有布爾值輸出，無論測試是成功還是失敗，不應該人工通過log來確認測試是否成功或者失敗。
e.及時，測試應及時編寫。單元測試應該恰好在使其通過的生產代碼之前編寫。如果在編寫生產代碼之后編寫測試，你會發現生產代碼難以測試。你可能會認為某些生產代碼本身難以測試。你可能不會去設計可測試的代碼。
第十章 類
1.單一權責原則，類或者模塊應有且只有一條加以修改的理由。
2.內聚，如果一個類中的每個變量都被每個方法所使用，則該類具有最大的內聚性。內聚性高，意味著類中的方法和變量相互依賴，相互結合成一個邏輯整體。
第十一章 系統
1.將系統的構造與使用分開
軟件系統應將起始過程和啟始過程之后的運行時邏輯分離開，在起始過程中構建應用對象，也會存在相互纏結的依賴關系。（延遲初始化可以加快程序運行速度）
1.1分解main
將程序的構造放到main，并使其與運行時邏輯分開，main只管構造并將構造后的數據對象發送給各個應用，或者被各個應用使用。但是，不參與運行時的任何邏輯控制。
1.2工廠模式
使用該模式可以將系統構造和系統運行時邏輯分開。
1.3依賴注入（需要強化理解）
1.4擴容
“一開始就做對系統”純屬神話。反之，我們應該只去實現今天的用戶故事，然后重構，明天再擴展系統，實現新用戶的故事。這就是迭代和增量敏捷的精髓所在。測試驅動開發，重構以及他們打造出的整潔的代碼。
1.5測試驅動系統架構
最佳的系統架構由模塊化的關注面領域組成，每個關注面均用純編程語言對象實現。不同的領域之間用最不具有侵害性的方面或類方面工具結合起來。這種架構就能測試驅動，就像代碼一樣。(需要關注面向切片編程(POJO))
1.6優化決策
模塊化和關注面切分成就了分散化管理和決策。在巨大的系統中，不管是一座城市或是一個軟件項目，無人能做所有的決策。最好是授權給最有資格的人。擁有模塊化關注面的POJO系統提供的敏捷能力，允許我們基于最新的知識做出優化的，時機剛好的決策。決策的復雜性降低了。
第十二章 迭進
12.1 通過迭進設計達到代碼整潔的目的：
通過這幾個原則可以讓你的設計變簡單（DIP，SRP）
1.運行所有測試
2.不可重復，
3.表達了程序員的意圖
4.盡可能減少類和方法的數量
5.以上規則按其重要程度排序
12.2 簡單設計規則1:運行所有測試
編寫的測試越多就越能持續走向編寫較易測試的代碼，緊耦合的代碼很難編寫測試。遵循有關編寫測試并持續運行測試的簡單，明確的規則，系統就會更貼近OO低耦合度，高內聚度的目標。編寫測試引致更好的設計。
12.3簡單設計規則2-4：重構
在重構過程中，可以應用有關優秀軟件設計的一切知識。提升內聚性，降低耦合度，切分關注面，模塊化系統性關注面，縮小函數和類的尺寸，選用更好的名稱，如此等等。這也是簡單設計原則后三條規則的地方:消除重復，保證表達力，盡可能減少類和方法的數量。
12.4 不可重復
12.5表達力
12.6盡可能少的類和方法
第十三章 并發編程
1.為什么要并發
并發是一種解耦策略。它幫我們把做什么和何時做分解開。
2.并發的防御原則
13.1 單一權責原則（SRP）
并發代碼應該從其他代碼中分離出來，因為，并發代碼相比于其他的代碼是很復雜的存在。但是，并發實現細節常常直接嵌入到其他生產代碼中。那么下面幾個問題需要考慮，
a.并發相關代碼由自己的開發，修改和調優生命周期
b.開發相關代碼由自己要對付的挑戰，和非并發相關代碼不同，而且往往更為困難
c.即便沒有周邊應用程序增加負擔，寫得不好的并發代碼可能的出錯方式數量已經足具挑戰性。
建議：分離并發相關代碼與其他代碼。
13.2 限制數據作用域
兩個線程修改共享對象的同一字段時，可能相互干擾，導致未預期的行為。解決方案之一是采用synchronized關鍵字在代碼中保護一塊使用共享對象的臨界區。限制臨界區的數量很重要。更新共享數據的地方越多，就越可能出錯。
建議：謹記數據封裝，嚴格限制對可能被共享的數據的訪問。
13.3 使用數據副本
避免共享數據的好方法之一就是一開始就避免共享數據。在某些情況下，有可能復制對象并以只讀方式對待。在另外一種情況下，有可能復制對象，從多個線程收集所有副本的結果，并在單個線程中合并這些結果。
13.4 線程盡可能地獨立
讓每個線程在自己的世界中存在，不與其他線程共享數據。每個線程處理一個客戶端請求，從不共享的源頭接納所有請求數據，存儲為本地變量。
建議：嘗試將數據分解到可被獨立線程操作的獨立子集。
13.5了解執行模型
13.5.1生產者－－－消費者模型
一個或多個生產者線程創建某些工作，并置于緩存或隊列中。一個或多個消費者線程從隊列中獲取并完成這些工作。生產者和消費者之間的隊列是一種限定資源。
13.5.2 讀者－－－作者模型
當存在一個主要為讀者線程提供信息源，但只偶爾被作者線程更新的共享資源，吞吐量就會是個問題。增加吞吐量，會導致線程饑餓和過時信息的積累。更新會影響吞吐量。協調讀者線程，不去讀作者線程正在更新的消息，這是一種辛苦的平衡工作。作者線程傾向于長期鎖定許多讀者線程，從而導致吞吐量問題。
挑戰之處在于平衡讀者線程和作者線程的需求，實現正確的操作，提供合理的吞吐量，避免線程饑餓。
13.5.3哲學家問題（故事內容不在這里描述）
從哲學家問題可以反映出編寫并發經常遇到的問題，死鎖，活鎖，吞吐量和效率降低等問題。那么學習這些基礎問題的解決算法可以幫助你解決大多數的并發問題，因為大多的并發問題都是上述問題的變種。
13.6 警惕同步方法之間的依賴
同步方法之間的依賴會導致并發代碼中的狡猾缺陷。Java語言有synchronized概念，可以用來保護單個方法。然而，如果在同一共享類中由多個同步方法，系統就可能寫得不太正確了。
建議：避免使用一個共享對象的多個方法。如果有時必須使用一個共享對象的多個方法。這種情況發生時，有３中寫對代碼的手段：
1.基于客戶端的鎖定－－客戶端代碼在調用第一個方法前鎖定服務端，確保鎖的范圍覆蓋了調用最后一個方法的代碼。
2.基于服務端的鎖定－－在服務端內創建鎖定服務端的方法，調用所有方法，然后解鎖。讓客戶端代碼調用新的方法。
3.適配服務端－－創建執行鎖定的中間層。這是一種基于服務端的鎖定例子，但不修改原始服務端代碼。
13.7保持同步區域微小
應該盡可能少地設計臨界區，如果有請盡可能減小同步區域。
13.8 編寫線程需要注意的幾點：
a.將偽失敗看作可能的線程問題
線程代碼中的缺陷可能在一千或者一百萬次執行中才會顯現一次。所以，不要將系統錯誤歸咎于偶發事件。
b.先使非線程代碼可工作
確保線程之外的代碼可以工作。不要同時追蹤非線程缺陷和線程缺陷。確保代碼在線程之外可以工作。
c.編寫可插拔的線程代碼
編寫在數個環境下運行的線程代碼
1.單線程與多線程在執行時不同的情況
2.線程代碼與實物或測試替身互動
3.用運行速度,緩慢和有變動的測試替身執行
4.將測試配置為能運行一定數量的迭代
建議：編寫可插拔的線程代碼，這樣就能在不同的配置環境下運行。
d.編寫可調整的線程代碼
在系統運行時允許線程發生變動。允許線程依據吞吐量和使用率自我調整。
e.運行多余處理器數量的線程
任務交換越頻繁，越有可能找到錯過臨界區或導致死鎖的代碼。
f.在不同平臺上運行
g.調整代碼并強迫錯誤發生
第14章 逐步改進
代碼并不是一次就能寫的很干凈的，需要我們不斷的迭代和優化。
第17章 味道與啟發
17.1注釋
a.不恰當的注釋信息
讓注釋傳達本該更好地在源代碼控制系統，問題追蹤系統或任何其他記錄系統中保存的信息，是不恰當的。例如，修改歷史記錄只會用大量過時而無趣的文本搞亂源代碼文件。注釋只應該描述有關代碼和設計的技術性信息。
b.廢棄的注釋
過時，無關或不正確的注釋就是廢棄的注釋。
c.冗余注釋
如果注釋描述的是某種充分自我描述了的東西，那么注釋就是多余的。注釋應該談及代碼自身沒有提到的東西。
d.注釋要寫就要寫最好的注釋，別畫蛇添足
e.注釋掉的代碼，看到注釋掉的代碼就刪。
17.2 環境
a.需要多步才能實現的構建
構建系統應該是單步的小操作。不應該從源代碼控制系統中一小點一小點簽出代碼。不應該需要一系列神秘指令或環境依賴腳本來構建單個元素。不應該四出尋找額外的小jar,xml文件和其他系統所需的雜物。你應該能夠用單個命令簽出系統，并單個指令構建它。
b.需要多步才能做到測試
你應該能夠用單個指令就可以運行全部單元測試。能夠運行全部測試是如此基礎和重要，應該快速，輕易和直接了當地做到。
17.3 函數
a.函數的參數應該少。
b.輸出參數違反直覺。如果非要修改，那就修改函數所在對象好了。
c.標示參數，布爾值參數宣告函數做了不止一件事，應該消滅掉，即函數只做一件事。
d.永不被調用的方法應該丟棄。
17.4 一般性問題
a.如果代碼需要有多種語言，那么應該盡力減少源文件中額外語言的數量和范圍。
b.明顯的行為未被實現，如果明顯的行為未被實現，讀者和用戶就不能再依靠他們對函數名稱的直覺。他們不再信任原作者，不得不閱讀代碼細節。
c.不正確的邊界行為，追索每種邊界條件，編寫測試。
d.忽視安全
e.重復，盡可能找到并消除重復。
f.在錯誤的抽象層級上的代碼，創建分離較高層級一般性概念與較低層級細節概念的抽象模型，這很重要。
g.基類不可多度依賴于派生類，基類應該對派生類一無所知。
h.信息過多，設計良好的模塊有著非常小的接口，讓你事半功倍。設計良好的接口并不提供許多需要依靠的函數，所以耦合度比較低。
優秀的軟件開發人員學會限制類或模塊中暴露的接口數量。類中的方法越少越好。函數知道的變量越少越好。類擁有的實體變量越少越好。隱藏你的數據。隱藏你的工具函數。隱藏你的常量和你的臨時變量。不要創建擁有大量方法或大量實體變量的類。不要為子類創建大量受保護變量和函數。盡力保持接口緊湊。通過限制信息來控制耦合度。
i.死代碼一定要刪除。
j.垂直分隔，變量和函數應該在靠近被使用的地方定義。私有函數應該剛好在其首次被使用的位置下面定義。
k.前后不一致，從一而終即一旦選中，就小心持續遵循。如果在特定函數中用了response的變量來持有HttpServletResponse對象，則在其他用到HttpServletResponse對象的函數中也用同樣的變量名。這樣會讓你的代碼更易閱讀。
l.混淆視聽，沒用的變量或者函數直接刪掉，以免造成不必要的干擾。
m.人為耦合，不互相依賴的東西不該耦合。一般來說，人為耦合是指兩個沒有直接目的之間的模塊的耦合。其根源是將變量，常量或函數不恰當地放在臨時方便的位置。
n.特性依戀，類的方法只應對其所屬類中的變量和函數感興趣，不該垂青其他類中的變量和函數。當方法通過某個其他對象的訪問器和修改器來操作該對象內部數據，則它就依戀于該對象所屬類的范圍。
o.選擇算子參數，盡量不要把boolean作為函數參數
p.晦澀意圖，代碼要盡可能具有表達力。
q.位置錯誤的權責，我們可以采用最小驚異原則來幫助我們即代碼應該放在讀者自然而然期待它所在的地方。
r.不恰當的靜態方法，對于沒有機會打算讓它有多態行為的函數可以作為動態函數，否則可選用靜態函數。
s.使用解釋性變量，命名要有意義。
t.函數名稱應該表達其行為
u.理解算法
v.把邏輯依賴改為物理依賴：
1.邏輯依賴：原始數據和業務邏輯之間的依賴關系。例如：
定義的常量和業務邏輯存在著依賴關系或者說被捆綁在了一起，即當業務邏輯發生變化或者存在其他可能性的時候且定義的常量無法滿足導致常量需要修改。
2.物理依賴：函數方法和業務邏輯之間的依賴關系。例如：
為了解決邏輯依賴的問題，我們可以通過構造一個方法將數據和業務隔離。
w.用多態替代if/else 或 switch/case
x.遵循標準約定
y.用命名常量替代魔術數，魔術數不僅僅指的是數字，也泛指任何不能自我描述的符號。
z.準確，在可以用List的時候，非要把變量聲明為ArrayList就過分拘束了。在代碼中做決定時，確認自己足夠準確。明確自己為何要這么做，如果遇到異常情況如何處理。別懶得理會決定的準確性。代碼中的含糊和不準確性要么是意見不同的結果，要么源于懶惰。無論原因是什么，都要消除。
z+1.結構甚于約定，堅守結構甚于約定的設計決策。
z+2.封裝條件，如果沒有if或while語句的上下文，布爾邏輯就難以理解。應該把解釋了條件意圖的函數抽離出來。
例如：
if(shouldBeDeleted(timer))
要好于
if(timer.hasExpired() && !timer.isRecurrent())
z+3.避免否定性條件，盡可能將條件表示為肯定形式。
z+4.函數只該做一件事
z+5.掩蔽時序耦合，排列函數參數，好讓它們被調用的次序顯而易見。
z+6.別隨意，構建代碼需要理由，而且理由應于代碼結構相契合。
z+7.封裝邊界條件，把處理邊界條件的代碼集中到一處，不要散落于代碼中。
z+8.函數應該只在一個抽象層級上，函數中的語句應該在同意抽象級上，該層級應該是函數名所示操作的下一層。
z+9.在較高層級放置可配置數據，如果你有個已知并在較高抽象層級的默認常量或配置值，不要將它埋藏到較低層級的函數中。把它作為較高層級函數調用較低層級函數時的一個參數。位于較高層級的配置性常量易于修改。它們向下貫穿應用程序。應用程序的較低層級并不擁有這些常量的值。
z+10.避免傳遞瀏覽，編寫害羞代碼。
z+11.不要繼承常量
17.5 測試
1.使用覆蓋率工具，覆蓋率工具能匯報你測試策略中的缺口。使用測試覆蓋率工具能更容易地找到不足的模塊，類和函數。
2.別略過小測試
3.被忽略的測試就是對不確定事物的疑問。
4.測試邊界條件
5.全面測試相近的缺陷，缺陷趨向于扎堆。
6.測試失敗的模式有啟發性
7.測試覆蓋率的模式有啟發性，查看被或未被以通過的測試執行的代碼，往往能發現失敗的測試為何失敗的線索。
8.測試應該快速
總結
以上是生活随笔為你收集整理的代码整洁之道内容概括的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： pythonopencv图像形态_Pyt
- 下一篇： [pytorch、学习] - 5.7 使