《代碼簡潔之道》-學習筆記

筆記：代碼整潔之道

命名：

 

　　　1、有意義，名副其實：降低代碼的模糊度，明確說明代碼的用途；

         2、避免誤導：accountList的類型最好就是List；

         3、避免使用多個不同之處較小的名稱；

         4、避免使用字母l和O，因為它們像數字1和0；

         5、做有意義的區分，只有意義不同時才使用不同的名字；

         6、廢話是無意義的區分，是冗餘；

         7、使用可搜尋的名稱：用宏定義數字比直接用數字好，避免使用單字母變數和數字常量；

         8、不必使用帶類型的匈牙利標記法；

         9、避免成員變數使用類名首碼；

         10、類名和對象名一般都是名詞和名詞短語；

         11、方法名一般是動詞和動詞短語；get,set,is首碼；

         12、使用解決方案領域內的名稱；

         13、添加有意義的語境：使用有意義的首碼，建立一個類並將變數聲明為成員變數；

         14、命名要精確：不要添加無意義的語境；

函數：

 

         1、短小：函數中的縮排層級不應該多於一層或者兩層；

         2、函數應該做一件事，做好一件事，只做一件事；

         3、每個函數只有一個抽象層級，其他的交給下面的抽象層來做；

         4、判斷函數只做了一件事：不能分函數區段；

         5、閱讀代碼，自頂向下規則：每個函數後面都跟著下一個抽象層的函數；

         6、如何讓switch只做一件事：通過類工廠建立實際類並返回父類引用，再使用抽象類別（父類引用）調用實際類重寫的函數；

         7、使用描述性的名字；

         8、函數參數：為了便於測試，應該少於2個；

         9、一元函數的3種形式：

　　　　　　①詢問關於參數的問題（判斷），②轉換參數的內容（要有傳回值），③參數是個事件（無傳回值）

         10、如果函數超過2元：應該將其中的某些參數封裝成類；

         11、函數名字：動/名詞形式；

         12、避免使用輸出參數：如果需要，應該修改所屬對象的狀態；

         13、一個函數要麼做一件事（指令），要麼回答一件事（詢問）；

         14、使用異常代替返回錯誤碼：這樣錯誤碼可以從主路徑代碼中分離出來，避免嵌套；

         15、分離try/catch塊：集中在一個函數中；

注釋：

 

　　1、  整潔清楚的代碼比注釋要好得多；

　　2、  真正好的注釋就是考慮不用寫注釋；

　　3、  需要注釋的地方：提供法律資訊；解釋方法的意圖；提供警告資訊；

　　4、  ToDo注釋，提示尚未完成的工作；

　　5、  避免括弧後面的注釋，應當減少嵌套，寫成方法；

　　6、  刪掉被注釋掉的代碼；

　　7、  注釋就是一種失敗；

格式：

 

　　1、  垂直上的間隔：不同的邏輯之間用空格間隔；

　　2、  垂直上的靠近：關係密切的邏輯要靠近才會更加清晰；

　　3、  變數在離使用最近的地方聲明；

　　4、  相關函數：放在一起，調用者放在被調用者的上面；

　　5、  概念相關：命名模式相同，應該放在一起；

　　6、  水平方向：以不拖動捲軸為準則；

　　7、  =，+=等前後的空格可以起強調的作用；

　　8、  縮排

　　9、  團隊規則

對象和資料結構（過程式代碼）：

 

　　隱藏實現關乎抽象，並不是簡單的添加取值器和賦值器；

　　1、  對象和資料結構的反對稱性：

　　　　過程式代碼便於在不改變既有代碼的同時，添加新的函數（過程）；

　　　　物件導向便於在不改變既有函數的情況下，添加新的類（對象），但是如果抽象類別添加新的函數，就需要修改抽象類別的所有子類；

　　2、  資料結構應該只有公開變數；對象應該只有私人變數和公有函數；

　　3、  對象暴露行為，隱藏資料；便於添加新物件類型而無需修改既有行為，同時也難以在既有的對象中添加新行為。

　　　　資料結構暴露資料，沒有明顯的行為；便於向既有資料結構添加新行為，同時也難以向既有函數添加新資料結構。

      4、The law of demoter : 模組不應瞭解它所操縱對象的內部情況。 火車失事，混雜，隱藏結構。

錯誤的處理：

 

　　1、  不要返回null值：這樣的話調用者就要處理null，增加工作量；

　　　　解決：拋出異常或者返回特例對象；

　　2、  不要傳遞null值：

　　3、  異常的處理：拋出異常或者返回特例對象；如果是調用第三方api可能產生異常，可以建立一個方法或異常類將第三方api打包；

　　4、  避免使用可控異常（checked exception）：因為處理它們需要修改函數頭，違反了開放-閉合原則；應該使用不可控異常（runtime exception），

保持邊界整潔：（電子書缺失）

 

　　1、  學習性測試：在項目中引入第三方api的新版本，測試專案是否正常工作；

　　2、  處理邊界問題方法：用新類封裝第三方api；用adapter模式將我們的介面轉換為第三方提供的介面；

　　　　更多設計模式：http://blog.csdn.net/qinysong/archive/2006/08/09/1041818.aspx

單元測試：

 

     1、測試驅動開發，整潔的測試有助於進行代碼的改動；

　　2、整潔測試的標準：可讀性；

　　3、雙重標準：由於運行環境的差異，測試代碼和生產代碼可以有不同的標準，如效率、記憶體等；

　　4、單個測試的斷言數量應該最小化，只測試一個概念；

　　5、F.I.R.S.T規則：

　　　　F fast:測試需要頻繁運行，因此要能快速運行；

　　　　I Independent：測試應該相互獨立；

　　　　R Repeatable：測試應當能在任何環境中重複；

　　　　S Self-validating：自足驗證，測試應該能看到成功與否的結果；

　　　　T timely：測試應該及時編寫，應該恰好在生產代碼之前編寫；

類：

 

　　1、類的組織：自頂向下原則，變數列表（公用先於私人，靜態先於實體），方法列表（工具方法緊跟在所屬方法之後）；

　　2、類應該短小：類名越明確，類的職責就越清晰；

　　　　（1）每個類單一權責，只有一個修改它的原因，並與少量的其他類協同完成工作；

　　　　（2）內聚：類中含有最少的變數，且每個方法都使用每個變數，此時內聚度最高，類應該是內聚高的；

　　3、隔離修改：具體類實現細節，抽象類別只呈現概念，利用介面和抽象類別可以隔離因為細節的改變而帶來的改變類的風險；

系統：

 

　　1、構造與應用代碼應該隔離開：就好像建設大樓時，構建大樓的吊車、鏟車之類的東西，在大樓投入使用時已經完全不存在一樣；軟體系統應該講啟動過程和啟動過程之後的運行時邏輯分開，在啟動過程中建立應用對象，也會存在相互的依賴。

　　　　public Service getService(){

　　　　　　return new MyServiceIml(...);

　　　　}

　　　　這種延遲化賦值的好處是：在使用對象之前不用關心這種架空構造；壞處是：必須實現這個構造方法，不然無法編譯，即使這個對象在運行時永遠不會被使用。

　　解決方案：

　　（1）分解main，將系統中的全部構造過程搬遷到main或者main模組中：main函數建立對象，再將對象傳遞給應用，應用直接使用；

　　（2）工廠，可以讓應用控制實體建立的時機；

　　（3）依賴注入，控制反轉IoC是依賴管理的手段，它將應用需要的依賴對象的建立權責從對象中拿出來，放在一個專註於此事的對象中，並通過依賴注入（賦值器）將依賴對象傳遞給應用；

　　2、擴容

　　AOP，面向方面變成。Java中三種方面和類似方面的機制：代理，純AOP架構，AspectJ

　　　　（1）Java代理：Proxy.newInstance(被代理介面，InvocationHandler h)方法執行後，被代理類的所有方法都會被加上Handler的處理邏輯，這是簡單的AOP，但是太複雜；

　　　　（2）純AOP架構：Spring AOP（需進一步瞭解）

　　　　（3）AspectJ語言

　　最佳的系統架構由模組化的關注面領域組成，每個關注面均用純Java對象實現。不同的領域之間用最不具有侵害性的方面或類方面工具整合起來。這種架構能測試驅動，就像代碼一樣。

2011-6-24 讀到173頁