每一個(gè)程序員有時(shí)候都需要重構(gòu)已有代碼。但在這么做之前卷哩，先思考一下下面這些事情，這可以節(jié)省你和其他人大量的時(shí)間（和苦惱）：
- 開始重構(gòu)的最佳方式是了解現(xiàn)有代碼庫并針對(duì)這些代碼編寫測試指黎。這有助于你了解這些代碼目前的優(yōu)點(diǎn)和弱點(diǎn)芯砸。這樣你就可以在避免錯(cuò)誤的同時(shí)保留寫得好的部分。我們都認(rèn)為我們能夠做的比現(xiàn)有系統(tǒng)好…直到最后并淋，由于我們沒有從現(xiàn)有系統(tǒng)的錯(cuò)誤中吸取教訓(xùn)寓搬，導(dǎo)致相比之前沒有什么提升，甚至更糟县耽。
- 避免重寫的誘惑句喷。最好的方式是盡可能的重用，無論多么丑的代碼兔毙，至少它經(jīng)過了測試唾琼、審查等等。拋棄現(xiàn)有代碼澎剥，尤其是在現(xiàn)有產(chǎn)品中的代碼锡溯，意味著拋棄幾個(gè)月（可能是數(shù)年）的測試，久經(jīng)沙場的代碼可能包含一些你不知道的臨時(shí)方案和 bug 修復(fù)哑姚。如果你沒有考慮到這些祭饭，你新寫的代碼可能就會(huì)重現(xiàn)那些在舊代碼中已經(jīng)修復(fù)的離奇問題。這將浪費(fèi)多年來所花費(fèi)的大量時(shí)間叙量，精力和收獲的知識(shí)倡蝙。
- 大量的迭代更新比一次巨大的改動(dòng)更好。增量更新可以通過反饋更輕松地衡量對(duì)系統(tǒng)的影響宛乃，比如通過測試悠咱。當(dāng)你修改了某處后，看見數(shù)百個(gè)測試失敗征炼，這一點(diǎn)也不好玩析既。可能讓你很有壓力并且感覺很糟糕谆奥，可能導(dǎo)致做出更糟糕的決策眼坏。少量的測試失敗比較容易處理，而且有很多處理的辦法。
- 在每次迭代后宰译，確遍苎粒現(xiàn)有測試都通過很重要。如果現(xiàn)有測試不夠覆蓋你的改動(dòng)沿侈，就補(bǔ)充新的測試闯第。千萬不要輕易刪掉舊的測試代碼。表面上看這些測試似乎對(duì)你的新設(shè)計(jì)沒什么用缀拭，但是深入地挖掘?yàn)槭裁匆砑舆@些測試很有價(jià)值咳短。
- 不應(yīng)該帶入個(gè)人偏好和一些主觀的內(nèi)容。如果這些代碼沒有問題蛛淋，干嘛要?jiǎng)铀茫看a風(fēng)格或結(jié)構(gòu)不符合你的偏好，這不是一個(gè)好的重構(gòu)理由褐荷。自認(rèn)為你可能比之前的人做的更好也不是一個(gè)正當(dāng)?shù)睦碛伞?/li>
- 新技術(shù)不是一個(gè)充分的重構(gòu)理由勾效。一個(gè)糟糕的重構(gòu)理由是，因?yàn)楝F(xiàn)有代碼還沒有使用當(dāng)前最酷的技術(shù)叛甫，而且認(rèn)為新的語言或框架可以做的更優(yōu)雅层宫。除非有成本-效益分析顯示新語言或框架，在功能性合溺、可維護(hù)性和生產(chǎn)效率上有顯著提升卒密，否則最好保持原樣。
- 切記棠赛，是人都會(huì)犯錯(cuò)誤哮奇。重構(gòu)不能保證新代碼總會(huì)更好，甚至不如以前睛约。我見過也親身經(jīng)歷過幾次失敗的重構(gòu)鼎俘。它不完美，但人力可為辩涝。
原文：Before You Refactor · 97 Things Every Programmer Should Know
