讀《敏捷開發必要技巧》—（1）

    不知道這算不算一本好書，但對我這個出入"IT江湖"的小白。這些技巧非常的受教。當然，在看完了這本書後，與之前自己瀏覽過的那本經典之作《重構—改善既有的代碼設計》有些地方存在吻合的。但是，這本書更令人如沐春風，為什嗎？我們程式員最喜歡的就是與源碼。不管怎樣，都會吼一聲"翠花，上源碼"。所以說，這本書的例子，更令我快速掌握其介紹的技巧（遺憾的是自己也沒完整的做過大部分練習，感覺很不爽）。不廢話了，免得忘了自己要做什麼！寫點讀書的筆記唄！

    書中的技巧都是針對現實編程中出現的實際問題而引出的，但是都需要我們在獲得此技巧時，也要注意一定的使用場合。

移除重複代碼

如何發現重複代碼？相信每個程式員都曉得咯！想想曾經寫的DAO那些代碼，你就寒心了。重複代碼多吧！個人感覺，邏輯結構相同的，有一樣的處理結果，在兩處地方以上出現等等，都需要的是自己如何判斷罷了，沒有書面的答案。

為什麼要移除重複代碼？我們不要指望程式碼數越多，就能帶來更大的優越感（曾經，初學編程時，我就以寫更長的程式為目的，能寫出來了，頗為自豪，但是在工作中，這點不可取）。Why？如果在某個N多地方出現的一樣功能的程式。那麼，你每一次的修改，都是一場噩夢！慢慢享受吧。如今的江湖，需要更精練的代碼。

將注釋轉換為代碼

    在軟體開發中，最讓我們受教的就是，在編碼中要加上適當的注釋，為的就是日後的代碼維護，不用猜字謎一樣猜某段代碼的功能了，畢竟你都加上注釋，是吧！

    但是，親愛的，你喜歡這樣的代碼嗎？你會暗地裡罵寫這代碼的人嗎？我想我知道你心裡所想(>_<)

    在這裡，我們能做什麼呢？我也曾記得應該給一個變數起一個有意義的名稱？為的    就是讓人一眼就知道這個變數所代表的意義！而不是加上一段注釋。如此可以避免你在    前幾行能記住這個變數的含義，但是隔了段時間或寫到N行後，我想你就忘了那個變    量兄弟究竟是幹嘛的了。

    有時候要捨得刪除額外的注釋？注釋具有讓人更容易的理解代碼的功能；而問題也    在於，因為常常沒有吧代碼寫清楚，所以才會找到注釋這個工具捷徑，好讓程式更讓人    容易理解。也往往讓我們忽略了好好的去組織代碼結構。長年累月，留下：本身 就不    清晰的代碼，加上一些不正確的注釋。

    書中給的建議：每一處注釋都是改進代碼的好機會

    針對上面的代碼，可以利用【注釋轉換為變數名】技法，解決。除了此法，還有以下列    表可供君參考：

    參數的注釋，轉化為參數名（其實剛剛那一條）

    將注釋轉換為方法的一部分

    刪掉沒用的注釋（不要因為可憐自己的勞動成果，而留下沒用的）

    可用方法名來表達注釋的意思（利用小方法，細化掉大方法體；讓代碼都處在自己所需    表達的意義的有效範圍內）

    。。。。。

去除代碼異味

出現代碼異味的原因是代碼的不穩定。在編寫代碼前，如何確定代碼是否穩定？一種有效而被動的方法是：當你第三次修改代碼時，就考慮這段代碼是不穩定的，是有異味的！

而普遍的代碼異味是，類別碼和switch運算式。以下提供些異味列表：

太多的注釋

類別代碼

switch if-then-else-if

想給一個變數 ，方法或者類名取個好名字時，也怎麼也取不好

用類似XXXUtil, XXXManager, XXXController 和其他的一些命

在變數，方法或類名中使用這些單詞"And"、"Or"等等

一些執行個體中的變數有時有用，有時沒用

一個方法的代碼太多，或者說方法太長

一個類的代碼太多，或者說類太長

兩個類都引用了彼此（相互依賴）

一個方法有太多參數

    對於普遍的類別碼移除，常見的兩種方法：

1.    用基於統一父類的不同子類代替不同的類別

2.    用一個類的不同對象代替不同的類別。    

 

    對於存在的"代碼異味"，更多的是要我們在發生變更時，需要修改類的內部，而不是    通過擴充或其他不動原來的類的方法進行變更。如此的代碼結構是有問題的，因為沒有    考慮到日後的代碼變更所帶來的額外工作量。也不符合【開閉原則】。在編碼中應該要    多多注意到這一基本原則，避免自己的代碼在日後的維護中，走向深淵！