你應該知道的《代碼整潔之道》

伴着2018年收官的鵝毛大雪，依舊在路上歡（Ku）快（B）馳騁，IT菜鳥分享今天的收穫--《代碼整潔之道》

1有意義的命名：

1. 名副其實（見名知意），add/insert/append
2. 避免使用與本意相悖的詞、專有名詞（hp,aix,sco等）。

例子：別用accountList來指稱一組賬號，除非它真是List類型。可用accountGroup或bunchOfAccounts，甚至直接用accounts都會好一些。

3）   提防使用不同之處較小的名稱。如：XYZControllerForAStrings和XYZControllerForBStrings

4）   做有意義的區分： sourceData和destinationData/targetData

5） 使用讀得出來的名稱：whs==woHenShuai

6） 使用可搜索的名稱： 名稱長短應與其作用域大小相對應。

7） 類名和對象應該是名詞或名詞短語，方法名應是動詞或動詞短語。

8)     每個概念對應一個詞，別用雙關語，使用解決方案領域名稱，使用源自所涉及問題領域的名稱，添加有意義的語境（state）

2函數

短小更短小，只做一件事(單一職責SRP、開放閉合OCP), 見名知意（setAndCheckIfExists）, 使用異常替代返回錯誤碼，抽離try/catch代碼塊。

3註釋：註釋簡單明瞭剛剛好，不多也不少。

4格式：縮進、水平對齊。一個開發團隊儘量保持一種格式規則。

5對象和數據結構

       對象曝露（pu lu）行爲--操作數據的函數，隱藏數據。便於添加新對象類型而無需修改既有行爲，同時也難以在既有對象中添加新行爲；數據結構曝露其數據，沒有明顯行爲。便於向既有數據結構添加新行爲，同時也難以向既有函數添加新數據結構。

       DTO（Data Transfer Objects-數據傳送對象），是一個只有公共變量、沒有函數的類。常用於數據庫通信、解析套接字傳遞的消息之類場景中。

6 錯誤處理：

使用異常而非返回碼，先寫try-catch-finally語句可以用TDD（測試驅動方法）構建其他代碼邏輯。

使用不可控異常（可控異常違反了開放/閉合原則），避免別返回null值和別傳遞null值。這一塊可以查看Java的可控異常（checked exception） 和 unchecked exception

7 邊界：邊界上的代碼需要清晰的分割和定義了期望的測試。應該避免我們的代碼過多的瞭解第三方代碼中的特定信息。

8 單元測試：測試嗲嗎和生產代碼一樣重要。

TDD三定律：

1. 在編寫不能通過的單元測試前，不可編寫生產代碼。
2. 只可編寫剛好無法通過的單元測試，不能編譯也算不通過
3. 只可編寫剛好足以通過當前失敗測試的生產嗲嗎。

每個測試都清晰地分爲三個環節：構造-操作-檢驗（Build-Operate-Check）。一是環節構造測試數據，二是操作測試數據，三個是不跟檢驗操作是否得到期望的結果。

9 類

類的名稱應當描述其權責。實際上，命名正是幫助判斷類的長度的第一個手段。自頂向下原則：如果有公共靜態常量，應該先出現，然後是私有靜態變量，以及私有實體變量。很少會有公共變量，公共函數應該跟在變量列表後面。

單一職責原則：類或模塊應有且有隻有一條加以修改的理由。類只應有一個權責—只有一條修改的理由。系統應該由許多短小的類而不是少量巨大的類組成。每個小類封裝一個權責，只有一個修改的原因，並與少數其他類一起協同達成期望的系統行爲。

內聚：類應該只有少量實體變量。類中的每個方法都應操作一個或多個這種變量。通常而言，方法操作的變量越多，就越粘聚到類上。

依賴倒置原則（DIP-Dependency Inversion Principle）：類應該依賴於抽象（接口或抽象類）而不是依賴於具體細節。

1. 系統---這部分可以關注一下springboot

將系統的構造和使用分開

軟件系統應將起始過程和起始過程後之後的運行時邏輯分離開，在起始過程中構建應用對象，也會存在相互纏結的依賴關係。

1. 分解main：將全部構造過程搬遷到main或被稱之爲main的模塊中，設計系統的其餘部分時，假設所有對象都已正確構造和設置。
2. 工廠：可以使用抽象工廠模式讓應用自行控制何時創建應用對象，但構造的細節卻隔離於應用程序代碼之外。
3. 依賴注入（DI – Dependency Injection/IOC-Inversion of Control）：控制反轉將第二權責從對象中拿出來，轉移到另一個專注於此的對象中，從而遵循了單一職責原則。在依賴管理中，對象不應負責實體化對自身的依賴。反之，它應當將這份權責移交給其他“有權力”的機制，從而實現控制的反轉。

真正的依賴注入還要更進一步。類並不直接分解其依賴，而是完全被動的。它提供可用於注入依賴的賦值器方法或構造器參數（或二者皆有）。在構造過程中，DI容器實體化需要的對象（通常按需創建），並使用構造器參數或賦值器方法將依賴鏈接到一起。至於哪個依賴對象真正得到使用，是通過配置文件或在一個有特殊目的構造模塊中編程決定。

1. 併發編程：

併發防禦原則：

1. 單一權責原則SRP

1. 限制數據作用域：

1. 使用數據複本：

1. 線程應儘可能地獨立

Java相關：

字節碼分析：第5行的是原子操作，Java內存模型中32位值的賦值操作是不可中斷的。

getNextId()方法中第09行的的++value 和 value ++ 的區別（初值爲42）如下：

 

前遞增和後遞增並不是原子的，什麼地方有共享對象/值，哪些代碼會導致併發讀/寫問題，如何防止這種併發問題發生。

非鎖定方案：CAS（比較並交換）AtomicBoolean/AtomicInteger/AtomicReference

非線程安全類：數據庫連接、Java.util中的容器、Servlet

方法之間的依賴可能破壞併發代碼：