重构,代码复用 重复代码
Ever had a moment in your software career where you needed to make a simple change, but found it hard to implement? The code was so fragile you couldn’t make your change without breakout myriads of tests? I’m guessing you have.
在您的软件职业生涯中，曾经有过需要做出简单更改但很难实施的时刻吗？ 代码是如此脆弱，如果没有无数的测试，就无法进行更改？ 我猜你有。
Or maybe it was a time when you couldn’t understand what caused a production problem while looking at the source. You couldn’t understand which code was executed or where to start. Logs and metrics couldn’t help either.
或者也许是您在查看源代码时不了解导致生产问题的原因的时候。 您无法理解执行了哪些代码或从哪里开始。 日志和指标也无济于事。
These are common symptoms of what I tend to refer to as “messy code.” It isn’t easy to work with, it isn’t easy to read, and it certainly isn’t easy to add new features too.
这些是我通常称为“混乱代码”的常见症状。 使用起来并不容易，阅读起来也不容易，添加新功能当然也不容易。
In cases like this, you should consider refactoring the code. Refactoring is taking code written in one way, changing its structure and implementation, while preserving the original code’s behaviors.
在这种情况下，您应该考虑重构代码。 重构采用一种方式编写的代码，在保留原始代码行为的同时，更改其结构和实现。
A definition I like to use is this:
我喜欢使用的定义是这样的：
refactoring is methodically making structural changes to existing code without adding, removing, or breaking functionality to easily add, remove, or modify functionality in the future
重构是有条不紊地对现有代码进行结构更改，而无需添加，删除或破坏功能，以便将来轻松添加，删除或修改功能
重构的价值 (The Value of Refactoring)
Refactoring is a useful skill to have. Knowing how to properly refactor code can help you when faced with messy code. It allows you to focus more on the changes you need to make for your task data hand.
重构是一项有用的技能。 面对混乱的代码时，了解如何正确重构代码可以为您提供帮助。 它使您可以将更多的精力集中在需要对任务数据进行的更改上。
It’s akin to knowing a handful of patterns or general algorithmic techniques. When faced with a new problem, most developers will apply patterns or algorithms they already know to solve new ones. Do you need to create different handlers for different event types? Using an abstract factory or flyweight pattern with a map data structure is a good starting spot. Do you need to search through a list of items that are always in sorted order? Using a binary search is what is you want.
这类似于了解少量模式或常规算法技术。 面对新问题时，大多数开发人员将使用他们已经知道的模式或算法来解决新问题。 您需要为不同的事件类型创建不同的处理程序吗？ 使用带有地图数据结构的抽象工厂模式或轻量化模式是一个很好的起点。 您是否需要搜索始终按排序顺序排列的项目列表？ 您想要使用二进制搜索。
Having a set of refactoring tools in your proverbial coding toolbox when faced with messy cod is the same idea. You can apply general refactoring patterns to the code right in front of you to make refactoring easier. Your energy and effort can stay focused on the actual problem you need to solve, not the refactor to enable it.
当您面对混乱的鳕鱼时，在谚语编码工具箱中拥有一组重构工具是相同的想法。 您可以将通用的重构模式应用于您前面的代码，以使重构更加容易。 您的精力和精力可以专注于您需要解决的实际问题，而不是重构来实现它。
I won’t go over the common refactoring patterns in this post — it would be too extensive (though I might post about them in the future!). You can find summaries of the ones from Martin Fowler’s excellent book Refactoring over at refactoring.com.
我不会在这篇文章中讨论常见的重构模式-它将过于广泛(尽管我将来可能会发表有关它们的信息！)。 您可以在refactoring.com上找到马丁·福勒(Martin Fowler)的出色著作《 重构》中的摘要。
但是，您如何知道何时重构代码？ (But How Do You Know When to Refactor Your Code?)
Great question! It’s tempting to say something trivial like “whenever you need to” or “all the time.” It is important to realize that there are times it might not be necessary or worthwhile to perform a refactor of your code.
好问题！ 很容易说些琐碎的话，例如“无论何时需要”或“一直”。 重要的是要意识到，有时可能没有必要或不值得执行代码重构。
To be clear, I am an advocate for earlier refactoring than not. Refactoring code is, after all, a reversible decision. You changed the original code, what is to keep you from changing it again? All code gets refactored at some point, including your refactors.
明确地说，我提倡提早重构。 毕竟，重构代码是一个可逆的决定。 您更改了原始代码，是什么使您无法再次更改它？ 所有代码在某个时候都会被重构，包括重构。
Here are some guidelines for when to refactor your code:
以下是何时重构代码的一些准则：
1.你脑子里争论了一个多小时。 (1. You debate in your head about it for more than an hour.)
If you have spent more than an hour tinkering with refactoring a piece of code, you should just do it.
如果您花了一个多小时来修补一段代码，则应该这样做。
Why? You have already spent enough time thinking about it to justify it.
为什么？ 您已经花了足够的时间考虑它，以证明它的合理性。
Time-box your effort if you think it might get complicated, and if it doesn’t work, no harm, no foul. If nothing else, you will have learned a lot about the code in the process. That knowledge can still inform the changes you need to make or help you write a specific story for refactoring.
如果您认为自己的工作可能会变得复杂，并且不起作用，则可以为您设定时间，没有危害，也没有犯规。 如果没有其他事情，您将在过程中学到很多有关代码的知识。 这些知识仍然可以告知您需要进行的更改，或帮助您编写特定的故事以进行重构。
2.简单的更改需要对三个或更多不同的组件进行其他更改。 (2. A simple change requires additional changes to three or more distinct components.)
I call this the “domino component” effect. If one component changes, so do another and another. If you find yourself having to make a slew of changes like this, you should refactor your code.
我称之为“多米诺骨牌成分”效应。 如果一个组件发生更改，则另一组件也要更改。 如果发现自己必须进行大量此类更改，则应重构代码。
Why? Because this means your components are tightly coupled. Tight coupling tends to make changes harder (see coupling for more).
为什么？ 因为这意味着您的组件紧密耦合。 紧密耦合往往会使更改变得更加困难(有关更多信息，请参见耦合 )。
The domino component effect also means that you will make it that much harder for the next person to make changes by forcing your changes into the current paradigm. You are causing your code’s maintainability to go down in this scenario; we always want to improve our codebase, not the other way around.
多米诺骨牌效应还意味着，通过将您的更改强加到当前范例中，您将使下一个人更难以进行更改。 在这种情况下，您使代码的可维护性下降了。 我们一直想改善我们的代码库，而不是相反。
3.您必须了解有关要更改的组件层次结构的细微差别。 (3. You had to understand nuances about the hierarchy of the component you were changing.)
Whenever you find yourself going up the inheritance tree level after level, you should refactor your code.
每当您发现自己又一步又一步地继承了继承树时，都应该重构代码。
Why? Because deep inheritance is just another form of tight coupling. It leads to fragile base classes, confusing sub-classes, and over time because challenging to maintain.
为什么？ 因为深层继承只是紧密耦合的另一种形式 。 它导致脆弱的基类，令人困惑的子类，并且随着时间的流逝，因为维护起来很困难。
Deep inheritance is, unfortunately, one of the hardest problems to refactor. If you have a deep hierarchy, by trying to change a base class or component, you automatically make those changes in all of the sub-classes too.
不幸的是，深层继承是最难重构的问题之一。 如果您的层次结构很深，则可以通过尝试更改基类或组件来自动在所有子类中进行那些更改。
These are, of course, just guidelines. It’s ultimately up to you to decide when to refactor your code. My personal experience is that refactoring early often is the best approach. Take a look at some code you wrote a few months ago, think of you could make it better, and give it a go!
当然，这些只是指导原则。 最终由您决定何时重构代码。 我的个人经验是，尽早进行重构通常是最好的方法。 看一下您几个月前编写的一些代码，想想您可以做得更好，然后尝试一下！
Happy refactoring!
重构愉快！
Originally published at https://dangoslen.me.
最初发布在 https://dangoslen.me 。
翻译自: https://medium.com/swlh/when-should-you-refactor-your-code-e98f3d33ff23
重构,代码复用 重复代码