|
|
這幾天，要對我半年前寫的代碼進行一些整理工作，在看代碼時發現當時有很多地方寫得不夠好，俗稱的有“壞味道”，呵呵，重構，必須的。
幾年前通讀過《重構，改善既有代碼的設計》一書，雖然對各種重構模式或方法記憶有限，但精髓還是記住了：改代碼而不改變軟件的外在表現，循序漸進。
其實，重構是一個開發人員的基本工作內容，是在每天的開發過程中都要用到的。離開了重構和測試，代碼質量是難有保障的。有人會說沒有用到重構，其實最簡單的例子，當你發現一個類中有幾處用到了相同的代碼，你把這幾行代碼提取到了一個私有函數中以供復用，這就是一次重構。所以說，別跟人炫耀你會重構，這是基本功。
好久沒更新博客了，借此說說我的一點心得吧。
1. 目的明確。代碼是一種平衡的產物，很多地方都在保持著某種平衡，有功能與性能的平衡，有可靠性與可維護性的平衡等等，每一次動手，都要有一個目標，是想改進局部代碼，還是想改進類結構，只有針對不同的目的才能實施不同的方法。
2. 評估影響。改動前，最好能有個預估，對可能產生的影響做到心中有數，以免引起不必要的后果。在“壞味道”的代碼中是很有可能牽一發而動全身的，要注意安全。如果只是對類的私有成員的改動，那通常影響的范圍有限，如果涉及到對公有成員或保護成員的改動，那就要注意了，簡單的評估方式是充分利用IDE的搜索、引用等功能，把引用過此成員的代碼行全部找出來，看看影響的范圍有多廣，如果有些代碼不在你的控制之內，那就要慎重考慮這個重構了。
3. 慎改結構。設計人員或架構師在定義類結構的時候一定有他的綜合考慮，在沒有充分理解之前，請慎重吧。不要拿設計模式去套現有的結構，設計模式是個指導，如果學完設計模式還在硬用來套用，那這種僵化的思維還不如不學的好。所以，當想要做這樣的重構時，請與你的設計師、架構師或有經驗的同事協作，除非你自己就是設計師。
4. 小步伐前進。每次改動盡量小，這樣可以把影響限制到小范圍。就像一個公式一樣，如果同時改變其中的幾個變量，那很難說是哪一個影響了結果，但如果一次只改變其中的一個，就可以確認其對結果的影響。尤其是當代碼已經完成了用戶需求，這時的重構只是為了讓代碼更好，切忌不要影響到已經得到用戶確認的外在表現。
5. 測試。無論你的開發是否是測試驅動，在重構時測試是保證代碼正確的必要手段。修改-編譯-測試，重復這個過程，直到達到目的。
當你花了幾分鐘或者幾個禮拜，已經讓代碼大為清爽的時候，回過頭來對比曾經的“壞味道”，我想，你會喜歡上代碼的，重構會發生在你寫下一行代碼的時刻，變成了編碼能力了。
少一行代碼，就少一分出錯的可能，別心疼你刪除掉的代碼，雖然那是你的心血，但那已經是歷史，在重構代碼中蛻變已經完成。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
