讀書筆記：
童子軍軍規：！！！
在意，如何在意代碼
消除重複代碼，提高表達力（所謂的表達力是？就是一看，就知道這代碼是幹啥的）
代碼越清晰，其他人花在理解上的時間也就越少
做到有表達力的最重要方式卻是嘗試，太多時候，我們寫出能工作的代碼，就轉移到下一個問題，沒下足功夫調整代碼，讓後來者易於閱讀
儘管使類，方法，函數等儘量少是重要的，但是跟重要的卻是：測試，消除重複和表達力
方法的行數也要儘量小而簡潔
看到47頁跳了
函數的第一原則，就是短小，20行封頂最佳
意味着有可能用大多數爲200行，最長500行的單個文件構造出色的系統，比如fitness，沒有一個超過500行的
不要返回null值，還不如返回空list，而且也不要把null值傳遞給函數的參數
測試代碼應該和生產代碼一樣重要，它該像生產代碼一般保持整潔
測試代碼三要素：可讀性，可讀性，可讀性
如何做到：明確，簡潔，還有足夠的表達力()
要像創建整潔的系統，需要有消除重複的意願，即使對於短短几行也是如此，“小規模複用”可大量降低系統複雜性
放進拿出，是重構過程中常見的事，重構有點像是解魔方，需要經過許多小步驟，才能達到較大目標。
當有多種異常需要處理的時候，可以專門構造一個異常類，比如書中的ArgsException，這樣其他代碼只要拋出該異常就可以了
SRP，單權責，業務代碼放到業務類，異常代碼放到異常類
優秀的軟件設計，大都關乎分隔-創建合適的空間放置不同種類的代碼。
註釋(comments)
/**
@param id
**
public void (String id)
C3: 註釋應該談及代碼自身沒提到的東西，而不是隻是一個參數列表
c5: 看到註釋掉的代碼，就刪掉它
環境(enviroment)
e2,e3: 需要多步才能實現的構建，需要多步才能做到的測試，這都不方便
函數(function)
f1: 函數的參數應該越少越好，三個以上參數堅決避免
f4: 永不被調用的方法應該丟棄，版本控制會記得它
java
j2 不要用接口定義常量，應該用只具有私有構造器的類來定義常量，也不要通過繼承常量接口來使用費常量
j3 最好用enum來代替常量，而且enum能實現的功能大於常量
test
t5 測試邊界條件，邊界容易錯誤
t6 缺陷傾向於扎堆，出現缺陷的地方，很有可能不止一個缺陷
name：
n5 名稱的長度於作用範圍的大小相關，範圍越大，長度越長，範圍小的可以用較短的名稱
g8 不要創建擁有大量方法和實體的類
g9 死代碼，即永遠不會運行到的代碼，就要刪掉
g10 本地變量的聲明和使用的垂直間距(行數)不要太遠
G11 前後不一致 ：不要前兩行的函數有返回值，後兩行沒有返回值
g17 函數實現的功能要和類有對應關係，不要在打印報表的代碼中計算員工打卡時間總數，這個計算應該放在打卡模塊
g19 使用 解釋性變量key = m[0] 和 value = m[1]，而不是用m[0],m[1]，這樣能增強表達力
g20 函數名稱也要具有表達力，表達其行爲
g21 理解算法的最好辦法，往往是重構函數，得到某種整潔而具有表達力的東西
g23 多態來代替if else和switch case，使用switch之前，先考慮使用多態，而且對於給定選擇類型，最好只有一個switch，它的多個case裏面有多態對象
g25 魔術數不僅指數字，還有不明意義的字符串
g28 如果if/while的條件語義不明顯，那麼可以對將條件封裝成shoudBeDeleted的函數
g29 否定式比肯定式更難懂些canBeCompacted>shouldNotBeCompacted，一個取反 > 三個取反
G32 別隨意： 寫代碼結構不能太隨意，太隨意其他人就會想修改他
G33 封裝邊界條件： 把處理邊界條件的代碼集中到一處，不要散落於代碼中，比如level+1在不同的地方出現很多次，那麼可以新建一個變量nextLevel = level +1, 用nextLevel來代替level + 1.
g35 可配置常量比如端口號，路徑名之類的，最好放在最高抽象層級
