重構代碼很危險:如何避免重構帶來的危險

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

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

　　對于你來說，它的邏輯看起來過于復雜，你沒有花時間去分析它。

　　你不理解為什么前任程序員要這樣編寫。

　　你著手的是一個很重要的系統，而且時間很緊。

　　你是團隊里的新成員，或新接觸這個項目，或這種語言。

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

　　現有的代碼對它要實現的功能顯得過于復雜，并且你分析過它。

　　修改后的代碼遠比現存的代碼邏輯要清晰。

　　你有足夠的時間，人手，財力來支持對項目進行回歸測試。

　　現有的代碼陳舊無效率。

　　無人認領的，寫的很爛的代碼都屬于此類。

　　跟你的一位同事談論對這部分程序進行重構的好處和存在的風險，你們兩個都贊成重構。

　　如何降低重構的風險

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

　　使用自動化的回歸測試，快速的驗證你的修改。這非常重要，如果沒有準備自動化測試，你應該在做任何修改前建好它。

　　盡量讓你的重構處于很短的開發周期，產品更新發布周期也盡可能短。

　　把你重構的代碼和其它程序隔離開，這樣能讓你更容易找到出問題的地方。

　　為你的重構活動準備測試計劃，包括回歸測試，功能測試，反向測試，負載測試，性能測試和用戶確認測試。

　　投入全部精力來研究其中的邏輯，不要分心做其它事情。

　　在需要的地方使用設計模式。不要為了設計模式而增加設計模式。設計模式應該用在合適的時間和合適地方。

　　小粒度重構

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

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

　　重構:改善既有代碼的設計

　　代碼整潔之道

　　Working Effectively with Legacy Code

　　程序員的職業素養

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

原文轉自：http://www.kjueaiud.com