重構代碼很危險，它會給測試工作增加巨大的負擔。除非你的程序需要重構，一定不要輕易重構代碼。我這里所說的并不是把一個for循環改成while 循環，或把一個StringBuffer改成StringBuilder，我說的是大動作，例如重寫一個方法，一個函數，甚至整個類或包。如果你缺乏對一個方法或一個類的了解，那你重構它的條件就不充分。即使你有一個天才的計劃，你也需要和團隊一起設計其中重大的修改。

當屬于下列情況時，你不該重構

• 對于你來說，它的邏輯看起來過于復雜，你沒有花時間去分析它。
• 你不理解為什么前任程序員要這樣編寫。
• 你著手的是一個很重要的系統，而且時間很緊。
• 你是團隊里的新成員，或新接觸這個項目，或這種語言。

當屬于下列情況時，你可以重構

• 現有的代碼對它要實現的功能顯得過于復雜，并且你分析過它。
• 修改后的代碼遠比現存的代碼邏輯要清晰。
• 你有足夠的時間，人手，財力來支持對項目進行回歸測試。
• 現有的代碼陳舊無效率。
  • 無人認領的，寫的很爛的代碼都屬于此類。
• 跟你的一位同事談論對這部分程序進行重構的好處和存在的風險，你們兩個都贊成重構。

如何降低重構的風險

權衡一下對一段代碼進行重構的利與弊，找出降低風險的方法。調試一段你經過重構但卻使產品崩潰的代碼，這對你來說將會是在這個行業中最有壓力的事情。

• 使用自動化的回歸測試，快速的驗證你的修改。這非常重要，如果沒有準備自動化測試，你應該在做任何修改前建好它。
• 盡量讓你的重構處于很短的開發周期，產品更新發布周期也盡可能短。
• 把你重構的代碼和其它程序隔離開，這樣能讓你更容易找到出問題的地方。
• 為你的重構活動準備測試計劃，包括回歸測試，功能測試，反向測試，負載測試，性能測試和用戶確認測試。
• 投入全部精力來研究其中的邏輯，不要分心做其它事情。
• 在需要的地方使用設計模式。不要為了設計模式而增加設計模式。設計模式應該用在合適的時間和合適地方。

小粒度重構

當你在開封一個方法時，如果你發現其中有一部分可以改進，那你就該考慮它，改進它。整潔的代碼是我們需要的，因為寫的很爛的代碼我們到處可見。和你的同事討論它們，當有人要修改你的代碼時不要固守己見。重構，然后回歸測試，然后才提交代碼。沒有人希望自己提交的代碼會弄垮系統。

下面是一些比較有深度的閱讀材料。

• 重構:改善既有代碼的設計
• 代碼整潔之道
• Working Effectively with Legacy Code
• 程序員的職業素養

忍住你的欲望，不要試圖重構你不理解的代碼。多問問題，努力能清楚他們為什么要把程序寫成這樣。也許他們有很好的理由。如果你找到一段很古老的代碼，很有可能它們是按照古老的方式寫的。每天都在新增的API，模式，需求和新領會都會讓這些老的方式顯得陳舊。不斷努力學習新的技術，但不要為了要使用這些技術而過于熱心的在重構中使用它們。

英文原文：Avoid the dangers of refactoring

譯文鏈接：http://www.aqee.net/avoid-the-dangers-of-refactoring/