如何避免重構帶來的危險
重構代碼很危險，它會給測試工作增加巨大的負擔。除非你的程序需要重構，一定不要輕易重構代碼。我這里所說的并不是把一個for循環改成while 循環，或把一個StringBuffer改成StringBuilder，我說的是大動作，例如重寫一個方法，一個函數，甚至整個類或包。如果你缺乏對一 個方法或一個類的了解，那你重構它的條件就不充分。即使你有一個天才的計劃，你也需要和團隊一起設計其中重大的修改。
當屬于下列情況時，你不該重構
- 對于你來說，它的邏輯看起來過于復雜，你沒有花時間去分析它。
- 你不理解為什么前任程序員要這樣編寫。
- 你著手的是一個很重要的系統，而且時間很緊。
- 你是團隊里的新成員，或新接觸這個項目，或這種語言。
當屬于下列情況時，你可以重構
- 現有的代碼對它要實現的功能顯得過于復雜，并且你分析過它。
- 修改后的代碼遠比現存的代碼邏輯要清晰。
- 你有足夠的時間，人手，財力來支持對項目進行回歸測試。
- 現有的代碼陳舊無效率。
- 無人認領的，寫的很爛的代碼都屬于此類。
- 跟你的一位同事談論對這部分程序進行重構的好處和存在的風險，你們兩個都贊成重構。
如何降低重構的風險
權衡一下對一段代碼進行重構的利與弊，找出降低風險的方法。調試一段你經過重構但卻使產品崩潰的代碼，這對你來說將會是在這個行業中最有壓力的事情。
- 使用自動化的回歸測試，快速的驗證你的修改。這非常重要，如果沒有準備自動化測試，你應該在做任何修改前建好它。
- 盡量讓你的重構處于很短的開發周期，產品更新發布周期也盡可能短。
- 把你重構的代碼和其它程序隔離開，這樣能讓你更容易找到出問題的地方。
- 為你的重構活動準備測試計劃，包括回歸測試，功能測試，反向測試，負載測試，性能測試和用戶確認測試。
- 投入全部精力來研究其中的邏輯，不要分心做其它事情。
- 在需要的地方使用設計模式。不要為了設計模式而增加設計模式。設計模式應該用在合適的時間和合適地方。
小粒度重構
當你在開封一個方法時，如果你發現其中有一部分可以改進，那你就該考慮它，改進它。整潔的代碼是我們需要的，因為寫的很爛的代碼我們到處可見。和你 的同事討論它們，當有人要修改你的代碼時不要固守己見。重構，然后回歸測試，然后才提交代碼。沒有人希望自己提交的代碼會弄垮系統。
下面是一些比較有深度的閱讀材料。
忍住你的欲望，不要試圖重構你不理解的代碼。多問問題，努力能清楚他們為什么要把程序寫成這樣。也許他們有很好的理由。如果你找到一段很古老的代 碼，很有可能它們是按照古老的方式寫的。每天都在新增的API，模式，需求和新領會都會讓這些老的方式顯得陳舊。不斷努力學習新的技術，但不要為了要使用 這些技術而過于熱心的在重構中使用它們。
[本文英文原文鏈接：Avoid the dangers of refactoring ]
來自: 外刊IT評論 http://www.aqee.net/
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！