在重構之前

每個程序員都會在某些時候需要重構已存在的代碼。但在這樣做之前請想想下面的問題，這會省去你和其他人很多時間（和痛苦）：

• 開始重構的最佳時機是審查代碼庫和代碼庫的測試代碼的時候。這時你明白當前代碼的優點和不足，這可以確保你重構時保持代碼的優秀特性並避免上個版本犯下的錯誤。我們都以為自己會比現存系統做得更好，結果並沒有更好，還可能更糟…這是因為我們沒有從前人的錯誤中吸取教訓。
• 避開推到重來的誘惑。復用的代碼越多越好。無論這些代碼多麽醜陋，這些代碼畢竟是被測試和復查過的。丟棄舊代碼，尤其是產品代碼，意味著你丟棄經年累月測試、實戰檢驗的代碼，這些代碼可能包含某些巧妙的設計，修復了一些你沒有察覺到的bug。如果你不考慮這些，你新寫的代碼可能會重現一些舊代碼已經修復的bug。這樣的做法浪費了這麽多年的時間和努力積攢的知識。
• 多次增量修改要好於一次大改。通過諸如測試結果一類的反饋，增量測試能夠讓你更容易把握改動對系統帶來的影響。一次修改過後測試出上百條錯誤可一點都不有趣。這會帶來焦慮和壓力，反過來使你更容易作出錯誤的決定。而只有幾條測試錯誤則好處理得多，使你的重構過程更加可控。
• 每次叠代之後，確保本次叠代通過測試是非常重要的。如果原來的測試代碼不能覆蓋本次修改，就增加新的測試以保證覆蓋率。在沒有充分的考慮之前不要丟棄舊代碼的測試。也許表面上這些測試已經不適用你的新設計了，但刨根問底地了解這些測試存在的原因是值得的。
• 不要讓你的喜好和自我成為你的障礙。如果一個東西沒壞，為什麽要修它呢？代碼的風格和結構不對你的胃口並不能構成重構的理由。自認為比前作者能寫出更好的程序也不能成為你進行重構的理由。
• 新技術作為重構的理由是不夠的。最糟糕的重構理由之一就是當前代碼使用的技術比起我們現在的酷炫技術已經落伍了，而我們覺得使用新的編程語言和框架能使功能實現得更優雅。除非通過成本——收益分析我們能得出使用新的語言和框架能使系統在功能、穩定性和效率上都有顯著的提高，否則最好先別動手。
• 記住人是會犯錯的。重構並不總能保證新代碼就一定比舊的更好，甚至不能保證和舊的一樣好我曾目睹和參與過一些失敗的重構。這並不美好，但人生就是這樣。

by Rajith Attapattu

Before You Refactor

At some point every programmer will need to refactor existing code. But before you do so please think about the following, as this could save you and others a great deal of time (and pain):

• The best approach for restructuring starts by taking stock of the existing codebase and the tests written against that code. This will help you understand the strengths and weaknesses of the code as it currently stands, so you can ensure that you retain the strong points while avoiding the mistakes. We all think we can do better than the existing system... until we end up with something no better — or even worse — than the previous incarnation because we failed to learn from the existing system‘s mistakes.

• Avoid the temptation to rewrite everything. It is best to reuse as much code as possible. No matter how ugly the code is, it has already been tested, reviewed, etc. Throwing away the old code — especially if it was in production — means that you are throwing away months (or years) of tested, battle-hardened code that may have had certain workarounds and bug fixes you aren‘t aware of. If you don‘t take this into account, the new code you write may end up showing the same mysterious bugs that were fixed in the old code. This will waste a lot of time, effort, and knowledge gained over the years.

• Many incremental changes are better than one massive change. Incremental changes allows you to gauge the impact on the system more easily through feedback, such as from tests. It is no fun to see a hundred test failures after you make a change. This can lead to frustration and pressure that can in turn result in bad decisions. A couple of test failures is easy to deal with and provides a more manageable approach.

• After each iteration, it is important to ensure that the existing tests pass. Add new tests if the existing tests are not sufficient to cover the changes you made. Do not throw away the tests from the old code without due consideration. On the surface some of these tests may not appear to be applicable to your new design, but it would be well worth the effort to dig deep down into the reasons why this particular test was added.

• Personal preferences and ego shouldn‘t get in the way. If something isn‘t broken, why fix it? That the style or the structure of the code does not meet your personal preference is not a valid reason for restructuring. Thinking you could do a better job than the previous programmer is not a valid reason either.

• New technology is insufficient reason to refactor. One of the worst reasons to refactor is because the current code is way behind all the cool technology we have today, and we believe that a new language or framework can do things a lot more elegantly. Unless a cost–benefit analysis shows that a new language or framework will result in significant improvements in functionality, maintainability, or productivity, it is best to leave it as it is.

• Remember that humans make mistakes. Restructuring will not always guarantee that the new code will be better — or even as good as — the previous attempt. I have seen and been a part of several failed restructuring attempts. It wasn‘t pretty, but it was human.

by Rajith Attapattu

註：本次更新間隔比較久，主要是有別的事要忙。同時自己也學習了一些翻譯的知識，力求提高翻譯質量。順便說下，本篇是本人第一次使用專業的翻譯軟件~

編程的97件事——6、在重構之前