不知道這算不算一本好書，但對我這個出入"IT江湖"的小白。這些技巧非常的受教。當然，在看完了這本書後，與之前自己瀏覽過的那本經典之作《重構—改善既有的代碼設計》有些地方存在吻合的。但是，這本書更令人如沐春風，爲什麼？我們程序員最喜歡的就是與源碼。不管怎樣，都會吼一聲"翠花，上源碼"。所以說，這本書的例子，更令我快速掌握其介紹的技巧（遺憾的是自己也沒完整的做過大部分練習，感覺很不爽）。不廢話了，免得忘了自己要做什麼！寫點讀書的筆記唄！
書中的技巧都是針對現實編程中出現的實際問題而引出的，但是都需要我們在獲得此技巧時，也要注意一定的使用場合。
移除重複代碼
如何發現重複代碼？相信每個程序員都曉得咯！想想曾經寫的DAO那些代碼，你就寒心了。重複代碼多吧！個人感覺，邏輯結構相同的，有一樣的處理結果，在兩處地方以上出現等等，都需要的是自己如何判斷罷了，沒有書面的答案。
爲什麼要移除重複代碼？我們不要指望代碼行數越多，就能帶來更大的優越感（曾經，初學編程時，我就以寫更長的程序爲目的，能寫出來了，頗爲自豪，但是在工作中，這點不可取）。Why？如果在某個N多地方出現的一樣功能的程序。那麼，你每一次的修改，都是一場噩夢！慢慢享受吧。如今的江湖，需要更精練的代碼。
將註釋轉換爲代碼
在軟件開發中，最讓我們受教的就是，在編碼中要加上適當的註釋，爲的就是日後的代碼維護，不用猜字謎一樣猜某段代碼的功能了，畢竟你都加上註釋，是吧！
但是，親愛的，你喜歡這樣的代碼嗎？你會暗地裏罵寫這代碼的人嗎？我想我知道你心裏所想(>_<)
在這裏，我們能做什麼呢？我也曾記得應該給一個變量起一個有意義的名稱？爲的 就是讓人一眼就知道這個變量所代表的意義！而不是加上一段註釋。如此可以避免你在 前幾行能記住這個變量的含義，但是隔了段時間或寫到N行後，我想你就忘了那個變 量兄弟究竟是幹嘛的了。
有時候要捨得刪除額外的註釋？註釋具有讓人更容易的理解代碼的功能；而問題也 在於，因爲常常沒有吧代碼寫清楚，所以纔會找到註釋這個工具捷徑，好讓程序更讓人 容易理解。也往往讓我們忽略了好好的去組織代碼結構。長年累月，留下：本身 就不 清晰的代碼，加上一些不正確的註釋。
書中給的建議：每一處註釋都是改進代碼的好機會
針對上面的代碼，可以利用【註釋轉換爲變量名】技法，解決。除了此法，還有以下列 表可供君參考：
參數的註釋，轉化爲參數名（其實剛剛那一條）
將註釋轉換爲方法的一部分
刪掉沒用的註釋（不要因爲可憐自己的勞動成果，而留下沒用的）
可用方法名來表達註釋的意思（利用小方法，細化掉大方法體；讓代碼都處在自己所需 表達的意義的有效範圍內）
。。。。。
去除代碼異味
出現代碼異味的原因是代碼的不穩定。在編寫代碼前，如何確定代碼是否穩定？一種有效而被動的方法是：當你第三次修改代碼時，就考慮這段代碼是不穩定的，是有異味的！ 而普遍的代碼異味是，類別碼和switch表達式。以下提供些異味列表：
太多的註釋
類別代碼
switch if-then-else-if
想給一個變量 ，方法或者類名取個好名字時，也怎麼也取不好
用類似XXXUtil, XXXManager, XXXController 和其他的一些命
在變量，方法或類名中使用這些單詞"And"、"Or"等等
一些實例中的變量有時有用，有時沒用
一個方法的代碼太多，或者說方法太長
一個類的代碼太多，或者說類太長
兩個類都引用了彼此（相互依賴）
一個方法有太多參數
對於普遍的類別碼移除，常見的兩種方法：
1. 用基於統一父類的不同子類代替不同的類別
2. 用一個類的不同對象代替不同的類別。
對於存在的"代碼異味"，更多的是要我們在發生變更時，需要修改類的內部，而不是 通過擴展或其他不動原來的類的方法進行變更。如此的代碼結構是有問題的，因爲沒有 考慮到日後的代碼變更所帶來的額外工作量。也不符合【開閉原則】。在編碼中應該要 多多注意到這一基本原則，避免自己的代碼在日後的維護中，走向深淵！
