這幾天，要對我半年前寫的代碼進行一些整理工作，在看代碼時發(fā)現(xiàn)當時有很多地方寫得不夠好，俗稱的有“壞味道”，呵呵，重構(gòu)，必須的。

　　幾年前通讀過《重構(gòu)，改善既有代碼的設(shè)計》一書，雖然對各種重構(gòu)模式或方法記憶有限，但精髓還是記住了：改代碼而不改變軟件的外在表現(xiàn)，循序漸進。

　　其實，重構(gòu)是一個開發(fā)人員的基本工作內(nèi)容，是在每天的開發(fā)過程中都要用到的。離開了重構(gòu)和測試，代碼質(zhì)量是難有保障的。有人會說沒有用到重構(gòu)，其實最簡單的例子，當你發(fā)現(xiàn)一個類中有幾處用到了相同的代碼，你把這幾行代碼提取到了一個私有函數(shù)中以供復(fù)用，這就是一次重構(gòu)。所以說，別跟人炫耀你會重構(gòu)，這是基本功。

　　好久沒更新博客了，借此說說我的一點心得吧。

　　1.目的明確。代碼是一種平衡的產(chǎn)物，很多地方都在保持著某種平衡，有功能與性能的平衡，有可靠性與可維護性的平衡等等，每一次動手，都要有一個目標，是想改進局部代碼，還是想改進類結(jié)構(gòu)，只有針對不同的目的才能實施不同的方法。

　　2.評估影響。改動前，最好能有個預(yù)估，對可能產(chǎn)生的影響做到心中有數(shù)，以免引起不必要的后果。在“壞味道”的代碼中是很有可能牽一發(fā)而動全身的，要注意安全。如果只是對類的私有成員的改動，那通常影響的范圍有限，如果涉及到對公有成員或保護成員的改動，那就要注意了，簡單的評估方式是充分利用IDE的搜索、引用等功能，把引用過此成員的代碼行全部找出來，看看影響的范圍有多廣，如果有些代碼不在你的控制之內(nèi)，那就要慎重考慮這個重構(gòu)了。

　　3.慎改結(jié)構(gòu)。設(shè)計人員或架構(gòu)師在定義類結(jié)構(gòu)的時候一定有他的綜合考慮，在沒有充分理解之前，請慎重吧。不要拿設(shè)計模式去套現(xiàn)有的結(jié)構(gòu)，設(shè)計模式是個指導(dǎo)，如果學(xué)完設(shè)計模式還在硬用來套用，那這種僵化的思維還不如不學(xué)的好。所以，當想要做這樣的重構(gòu)時，請與你的設(shè)計師、架構(gòu)師或有經(jīng)驗的同事協(xié)作，除非你自己就是設(shè)計師。

　　4.小步伐前進。每次改動盡量小，這樣可以把影響限制到小范圍。就像一個公式一樣，如果同時改變其中的幾個變量，那很難說是哪一個影響了結(jié)果，但如果一次只改變其中的一個，就可以確認其對結(jié)果的影響。尤其是當代碼已經(jīng)完成了用戶需求，這時的重構(gòu)只是為了讓代碼更好，切忌不要影響到已經(jīng)得到用戶確認的外在表現(xiàn)。

　　5.測試。無論你的開發(fā)是否是測試驅(qū)動，在重構(gòu)時測試是保證代碼正確的必要手段。修改-編譯-測試，重復(fù)這個過程，直到達到目的。

　　當你花了幾分鐘或者幾個禮拜，已經(jīng)讓代碼大為清爽的時候，回過頭來對比曾經(jīng)的“壞味道”，我想，你會喜歡上代碼的，重構(gòu)會發(fā)生在你寫下一行代碼的時刻，變成了編碼能力了。

　　少一行代碼，就少一分出錯的可能，別心疼你刪除掉的代碼，雖然那是你的心血，但那已經(jīng)是歷史，在重構(gòu)代碼中蛻變已經(jīng)完成。

it知識庫：在代碼重構(gòu)中蛻變，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。