06重构之前

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.
避免重写全部代码的诱惑。 重用尽可能多的代码。不管代码有多差，它都已经过测试和审查。扔掉旧代码---特别是在生产环境中---意味着扔掉几个月(或几年)的经过测试的、久经沙场的代码，这些代码可能有一些你不知道的变通办法和bug补丁。如果不考虑这一点，你编写的新代码可能会出现与旧代码中已修复的相同的神秘错误。这将浪费很多时间、精力和多年来获得的知识。
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.
记住人类会犯错。 重构并不总能保证新代码会比以前的代码更好，甚至不能保证和以前的代码一样好。我已经看到并参与了几次失败的重构。那些老代码并不漂亮，但它至少正常工作。

Previous05简单即是美 Next07谨慎提取共享代码

Last updated 6 years ago

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.
避免重写全部代码的诱惑。 重用尽可能多的代码。不管代码有多差，它都已经过测试和审查。扔掉旧代码---特别是在生产环境中---意味着扔掉几个月(或几年)的经过测试的、久经沙场的代码，这些代码可能有一些你不知道的变通办法和bug补丁。如果不考虑这一点，你编写的新代码可能会出现与旧代码中已修复的相同的神秘错误。这将浪费很多时间、精力和多年来获得的知识。
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.
记住人类会犯错。 重构并不总能保证新代码会比以前的代码更好，甚至不能保证和以前的代码一样好。我已经看到并参与了几次失败的重构。那些老代码并不漂亮，但它至少正常工作。