重构：改善既有代码的设计_技术债务：通过重构来拯救传统代码

向右看齐 2022-12-03 01:58 139阅读 0赞

重构：改善既有代码的设计

*How can you get a legacy codebase under control and bring it to a new level of maturity? In this post, Jeroen summarizes the lessons learned from years of working on a large legacy web application. This article was originally published by [intracto][].*

*您如何才能控制遗留代码库并将其提升到新的成熟水平？* *在本文中，Jeroen总结了多年来在大型遗留Web应用程序上工作所获得的经验教训。* *本文最初由[intracto][]发表。*

--------------------

## 可以通过重构保存旧版代码 **(**Legacy Code Can Be Saved by Refactoring**)** ##

I have good news for you! Squirrels plant thousands of new trees every year by simply forgetting where they leave their acorns. Also: **your project can be saved**.

我有个好消息要给你！ 松鼠每年只需忘记忘记橡子在哪里，就可以种植数千棵新树。 另外： **您的项目可以保存** 。

No matter how awful a muddy legacy code mess your boss has bravely volunteered for you to deal with, there *is* a way out of the mire. There will be twists and turns along the way, and a monster behind every other tree. But, one step at a time, you will get there.

不管您的老板勇敢地自愿为您处理混乱的旧代码，这*是*多么糟糕的事情。 一路上曲折，每隔一棵树后面都有一个怪物。 但是，一次只有一步，您会到达那里。

### 惧怕邪恶 **(**Fear no evil**)** ###

Fair enough, you didn’t ask for this horrific quest. The blood-covered ‘Here Be Dragons’ sign near the entrance of the code swamp induces a strong urge to call in sick for the next couple of years. At first glance, you’d rather have some light lunch first, and perhaps a leisurely stroll through the meadow after that, than being the petrified peasant to rid said swamp of its monsters.

公平地说，您并没有要求执行这个可怕的任务。 在代码沼泽入口附近被鲜血覆盖的“ Here Be Dragons”标志引起强烈的强烈要求，在接下来的几年中请病假。 乍一看，您宁愿先吃些轻便的午餐，然后再悠闲地漫步在草地上，而不是成为石化农民以摆脱沼泽中的怪物。

![Murky forest][]

Unfortunately though, you are forced past the sign by a galant yet firm nudge from the boss, who will stay behind to defend the town and in the process have some light lunch with the duke owning the swamp.

但是不幸的是，老板的勇敢而坚定的推动迫使您走过路标，老板会留下来捍卫城镇，并在此过程中与拥有沼泽的公爵共进午餐。

Bar some drastic measures, you can’t change these basic facts. However, **you *can* turn a swamp into a magnificent meadow** with just one muddy patch where cows live!

除非采取一些严厉措施，否则您无法更改这些基本事实。 但是， **您*可以*将沼泽变成一片壮丽的草地** ，那里只有一个泥泞的**牧场** ，牛可以在那里生活！

## 技术债务：如何获得这种方式？ **(**Technical Debt: How Did It Get This Way?**)** ##

As you poke and prod the area just past the warning sign with a stick, you might wonder: how on earth can anyone have let this happen? *Someone must have seen this coming, surely?* Were the people who wrote this code *that* incompetent?

当您用棍棒戳和刺穿警告标志旁边的区域时，您可能会想知道：到底有谁能做到这一点？ *肯定有人看到过这种情况吗？* 是谁写了这个代码*，*不称职的人吗？

Possibly. But not more so than anyone else. When push comes to shove, however confident people might seem, nobody else knows what they’re doing either.

可能吧 但没有比其他任何人更合适的了。 当推到顶峰时，无论人们看起来多么自信，其他人都不知道他们在做什么。

**Incompetence is far from the whole story.** The principle at work here is usually referred to with a metaphor: [Technical Debt][].

**无能远非整个故事。** 这里工作的原理通常被喻为： [技术债务][Technical Debt] 。

### 代码癌 **(**Code cancer**)** ###

The idea is that during development of any project, shortcuts will be taken. Ugly hacks will be allowed to get ahead quickly, just this once. This way, a debt is accumulated: code that does the job any way it can but is completely incapable of being maintained properly, let alone built upon.

这个想法是，在任何项目的开发过程中，都会采用捷径。 丑陋的骇客将被允许Swift取得成功，仅此一次。 这样，债务就累积起来了：代码会尽其所能地完成工作，但是完全无法正确维护，更不用说建立在上面了。

And so, bit by bit, a project’s code is corrupted. Nobody cares about this as long as they’re not the one having to touch it. But eventually someone has to, and it will probably be you.

因此，一点点地，一个项目的代码已损坏。 只要他们不是必须触摸它的人，就没人关心它。 但是最终有人必须这样做，并且可能是您。

This principle is at work in any project, and if it isn’t it most likely means you’re not moving fast enough. Your competition *will* take shortcuts, getting new features out more quickly. As a result, *your precious users will leave*, and join the party in the swamp next door and have a Long Island Iced Tea at the cocktail bar there instead of standing in your impeccable square meter meadow you’ve painstakingly created over the past year. Your meadow might be pretty in and of itself, but there’s just not much going on there.

该原则在任何项目中都起作用，如果不是，则很可能意味着您的移动速度不够快。 您的竞争*将*采用捷径，更快地推出新功能。 结果， *您的宝贵用户将离开* ，并加入隔壁沼泽中的聚会，并在那里的鸡尾酒吧享用长岛冰茶，而不必站在过去一年来辛苦创建的无可挑剔的平方米草地上。 您的草地本身可能很漂亮，但是那里没有太多活动。

![party swamp color][]

So, **any healthy project will accumulate some technical debt**, but in order not to go bankrupt — the code getting so hard to maintain it becomes unmanageable — at some point this debt will have to be settled.

因此， **任何健康的项目都将积累一些技术债务** ，但为了不破产(变得难以维护的代码变得难以管理)，在某个时候必须解决这些债务。

That is where the frightened and resentful peasant comes in, *forced to pay the debt* in the swamp owner’s stead. Paying this debt is often referred to as [refactoring][]: swapping a bit of code with another bit that does exactly the same but can be maintained and expanded more easily.

那里是受惊和愤慨的农民进来的地方， *被迫以*沼泽主人的名义*偿还债务* 。 偿还这笔债务通常被称为[重构][refactoring] ：将一部分代码与另一部分代码完全相同，但是可以更轻松地维护和扩展。

## 说服客户 **(**Persuading the Customer**)** ##

The duke, being the owner of the swamp, has a bit to say about which monsters you should be adding. There are always *new features* your customer wants to implement, the deadline for each one is last week and you should feel incompetent for not having finished all of them two weeks ago. So you will probably have a bit of explaining to do to convince him he needs to *let you rebuild* what he perceives as being in his possession already.

公爵是沼泽的主人，对于要添加哪些怪物还有一点要说。 您的客户总是想要实现一些*新功能* ，每个*功能*的截止日期都是上周，您应该感到无能为力，因为两周前没有完成所有这些功能。 因此，您可能需要做一些解释才能说服他，他需要*让您重建*他认为已经属于他的东西。

This is a critical point. If you *don’t succeed* in swaying your customer to start paying what he owes, technical debt will grow to the point of collapse. You will be the guy left in the rubble, held accountable.

这是一个关键点。 如果您*未能成功*地控制客户开始偿还欠款，技术债务将增加到崩溃的地步。 您将是留在废墟中的那个人，负责任。

![mayhem][]

In the end, **your customer and you want exactly the same thing**: have a fun and painless job that earns everyone involved a living. This follows from a *stable project* built from code you can change without the whole thing coming down on top of you.

最后， **您的客户和您想要一模一样的东西** ：拥有一份有趣而轻松的工作，使每个人都谋生。 这是从一个*稳定的项目开始的* ，该*项目*由您可以更改的代码构建而成，而整个过程不会落到您的头上。

### 为自由而战 **(**Fight for your freedom**)** ###

So for your own good, you need to make the situation clear. I think the best way to do it is to describe the impending doom lurking just around the corner, what the alternative is, and let the swamp owner know your good intentions:

因此，为了自己的利益，您需要弄清楚情况。 我认为最好的方法是描述即将来临的厄运，替代品是什么，然后让沼泽主人知道您的良好意图：

*  **Explain what technical debt means**, and how it makes development slow down to a halt if it gets too high. The customer has to realize in which ways this will cost him: time spent finding bugs, fixing them and creating new ones, insufficient time to add features and advance his business.
    
    **说明技术债务的含义** ，以及如果**技术债务**过高，它将如何使发展放缓到停止状态。 客户必须意识到这将以何种方式使他付出代价：花时间查找错误，修复错误并创建新错误，没有足够的时间来添加功能并促进业务发展。
 *  **Refactor with clear short-term goals in mind**. You can add a new feature in a week, or you can refactor for a week and add it in a day, with the prospect of being able to add similar features in the future very easily. Show how option two will be more expensive short term but infinitely cheaper in the long term.
    
    **考虑到明确的短期目标进行重构** 。 您可以在一周内添加新功能，也可以重构一周并在一天之内添加它，以期将来能够非常轻松地添加类似功能。 说明选项二短期内将变得更昂贵，但从长期来看将无限地便宜。
 *  **Point out that you want the best for your customer** and yourself, and that these two concerns are really the same thing.
    
    **指出您想要为客户**和**您**自己谋取最大利益，而这两个问题实际上是一回事。

Once you have the swamp owner on your side, the hardest part is over. You now have the freedom to *move the project in the right direction*.

一旦有了沼泽主人，最困难的部分就过去了。 您现在可以自由地*朝正确的方向移动项目* 。

## 没有新的沼泽 **(**A New Swamp Do Not Make**)** ##

You can recover from a huge mess; *don’t replace it with a new one*. Greenfield rewrites seldom work out; most never get released.

您可以从一团糟中恢复过来； *不要用新的代替它* 。 格林菲尔德很少重写。 大多数永远不会被释放。

When you finally convince the duke that people who stroll into his swamp consistently don’t come out again, he might want to build a new version. You might be tempted to comply, starting anew using shiny new tools, convinced everything will be better when you’re done. **Don’t.**

当您最终说服公爵相信不断陷入沼泽的人们不会再出来时，他可能想要构建一个新版本。 您可能会愿意遵守，使用崭新的工具重新开始，确信完成后一切都会更好。 **别。**

![caution][]

The main risks of a rewrite, as I see it, are:

如我所见，重写的主要风险是：

*  **The Big Red Button Switch**: the new code has never run in production before and is guaranteed to explode on first production use.
    
    **大红色按钮开关** ：新代码从未在生产中运行过，并且保证在首次使用时会爆炸。
 *  **Migration of data**: exporting and importing data from the old system while keeping up with live data coming in is likely to go wrong.
    
    **数据迁移** ：从旧系统中导出和导入数据，同时跟上实时数据的导入可能会出错。
 *  **Mistakes old and new**: while rewriting code, you will create bugs, recreate old bugs, miss subtleties and implicit features … Often these problems will occur in parts of the system that were not really problematic to begin with. You lose lots of time while not adding any value to the business of your customer.
    
    **新旧错误** ：在重写代码时，您将创建错误，重新创建旧错误，遗漏细微之处和隐式功能……通常，这些问题会出现在系统中并非真正有问题的部分。 您浪费了很多时间，却没有为客户的业务增加任何价值。
 *  **Keeping up with the business**: during the long time you’re working on the new project, the old project needs to keep evolving with the business needs as well. The new code will need to rebuild the old features *and* add the new features continually being added to the old project.
    
    **跟上业务发展** ：在长期从事新项目的过程中，旧项目也需要跟上业务需求的发展。 新代码将需要重建旧功能*并*添加不断添加到旧项目中的新功能。

**So, don’t start over. Improve what you have.**

**所以，不要重新开始。** **改善您所拥有的。**

## 使问题可见 **(**Make Problems Visible**)** ##

This might sound vaguely unpleasant, but the monsters in your swamp should be spitting in your face, dragons burning off the hairs on your arms, the gnome living near the mushroom-shaped rock kicking you in the shins.

这听起来似乎令人不愉快，但是沼泽中的怪物应该在您的脸上吐痰，巨龙烧掉手臂上的毛发，侏儒生活在蘑菇状岩石附近，将您踢到小腿上。

**These nuisances are in there ruining your project**, whether you notice them or not. You need to face them in order to get rid of them. You need to be able to **see what is going wrong** at any point in time.

无论您是否注意到**这些麻烦，都会破坏您的项目** 。 您需要面对他们才能摆脱它们。 您需要能够随时**查看发生了什么问题** 。

*  **Visualize errors**: make some time every week to fix some of the errors that occur most often. Eventually the graph will flatline, hopefully beating you to it.
    
    **可视化错误** ：每周花一些时间修复最常发生的错误。 最终，图形将趋于平坦，希望能击败您。
 *  **Monitor your environment**: this is critical in diagnosing bottlenecks and impending crises (see next paragraph).
    
    **监视您的环境** ：这对于诊断瓶颈和即将发生的危机至关重要(请参阅下一段)。

![errors][]

Now you know where and when it hurts, enabling you to administer first aid instead of potentially spending all your time scratching itches on a dying man.

现在您知道了何时何地受到伤害，使您能够进行急救，而不必花费所有时间在垂死的人身上挠痒。

## 对抗最受伤害的事物 **(**Fight What Hurts Most**)** ##

Next, it is vital to have a **vision of the system as it ought to be** in a perfect world — a mental picture over your ultimate meadow guiding your every move:

接下来，至关重要的**是对系统**进行**构想，因为它应该**处于一个完美的世界中-在最终草甸上的心理图片指导着您的一举一动：

![perfect meadow][]

Scratch it in the mud so you don’t forget. By taking **small intermediate steps in the direction of heaven**, you will find yourself looking through the fence eventually.

在泥中刮擦，这样您就不会忘记。 通过**朝着天堂的方向**采取一些**小中间步骤** ，您最终会发现自己正穿过篱笆。

The key is now to take the information you get from your monitoring tools, and the yearning for Valhalla, combining the two to decide **which problem to tackle first**. Your biggest problem might not be a realistic goal right away, but *start refactoring manageable roadblocks first* and make your way there.

现在的关键是，从监视工具中获取信息，并获取对Valhalla的向往，将两者结合起来，确定**首先要解决的问题** 。 您最大的问题可能不是立即实现一个现实的目标，而是*首先开始重构可管理的障碍，*并逐步实现目标。

The cripple pixie that seems cross with you for some reason might annoy you, but she’s harmless. Your time is better spent contemplating how to kick the ogre out.

出于某种原因与您交叉的cross弱小精灵可能会惹恼您，但她无害。 您的时间最好花在思考如何将食人魔踢出去上。

## 此代码是我的 **(**This Code Is Mine**)** ##

Fixing problems that matter is essential, but this **does not imply details do not matter**. In fact, they are probably just as important.

解决至关重要的问题，但这**并不意味着细节无关紧要** 。 实际上，它们可能同样重要。

![swamp camping][]

The [Boy Scout rule][] of **keeping the camping ground cleaner than you found it** is rule number one in the swamp survival guide. By continually cleaning up clutter, taking care not to leave new filth anywhere, your environment will get ever cleaner, until you find yourself in the pristine meadow you crave.

**保持露营地清洁的** [童子军规则][Boy Scout rule]是沼泽生存指南中的第一条规则。 通过不断清理杂物，注意不要在任何地方留下新的污物，您的环境将变得更加清洁，直到您发现自己渴望的原始草地。

To achieve this, attitude is everything. Strive towards clean code.

为此，态度就是一切。 努力编写干净的代码。

*  **You have to care**: the code is yours and anyone who touches it has to answer to you. Sloppiness and carelessness can not be tolerated.
    
    **您必须注意** ：代码是您的，任何触摸它的人都必须回答您。 不能容忍草率和粗心。
 *  **The whole team has to care**: however much trouble you go through to clean up a project, if somebody undoes your hard work behind you, you’re getting nowhere.
    
    **整个团队都必须关心** ：清理项目遇到了多大麻烦，如果有人撤消了您的辛苦工作，您将一事无成。
 *  **Discipline is of the essence**: once you (*or any team member!*) start letting things slide, it will be next to impossible to escape.
    
    **纪律至关重要** ：一旦您( *或任何团队成员！* )开始放任自流，几乎就不可能逃脱。
 *  **Keep taking small steps**: in the right direction, of course. Progress is way more important than achieving perfection.
    
    **继续采取小步骤** ：当然，朝正确的方向前进。 进展比实现完美更为重要。
 *  **Small victories generate momentum**: you will start seeing really nice patches of code, inducing you to clean up adjacent patches as well.
    
    **小小的胜利会产生动力** ：您将开始看到非常不错的代码补丁，并诱使您清理相邻的补丁。

## 建立图书馆 **(**Build a Library**)** ##

A good indicator of civilization is the number of libraries per square meter. Therefore, to introduce civility into your project, this seems like an excellent approach.

一个很好的文明指标是每平方米的图书馆数量。 因此，要将文明引入您的项目，这似乎是一种极好的方法。

![library][]

Even the most treacherous morass will have, here and there, a few spots that aren’t too bad on their own. Whenever you find a bit of code that does a thing well, **move it to your brand new library** so it can be reused.

即使是最危险的沼泽，到处也会有一些斑点，它们本身并不是太糟。 每当您发现执行良好的代码时， **请将其移至全新的库中**以便可以重用。

Doubtless, the code you’re expected to rescue will do things completely wrong. It will somehow completely ignore and circumvent any standards or best practices that would make your life as a developer easier. Nobody will fix this for you, there is only one way to go: *start following these practices and standards in your new code*.

毫无疑问，您希望挽救的代码将完全出错。 它将完全忽略并规避任何标准或最佳实践，这些标准或最佳实践将使您作为开发人员的生活更加轻松。 没有人会为您解决此问题，只有一种方法： *开始在新代码中遵循这些实践和标准* 。

**Make available industry-standard components or modules** and start using them. You will have code using old or custom ways to accomplish things, but that doesn’t mean you can’t build new stuff the proper way.

**提供可用的行业标准组件或模块**并开始使用它们。 您将拥有使用旧的或自定义的方式完成工作的代码，但这并不意味着您无法以正确的方式构建新的东西。

### 使用新工具进行重构 **(**Refactor using your new tools**)** ###

Once the tools are there, you can **refactor** existing code to use them as well. You don’t have to keep a marathon sprint to do this; just whenever you stumble upon a case that does things the old way, fix that case. Small steps. You will get to a point where everything is replaced and you won’t recognize the old code anymore.

一旦有了这些工具，您就可以**重构**现有代码以使用它们。 您无需保持马拉松短跑的速度； 只要您偶然发现一个用旧方法处理的案例，就修复该案例。 小步骤。 您将到达一切都被替换的地步，并且您将不再识别旧代码。

Often, code would be quite acceptable, if it weren’t for the myriad **dependencies** scattered throughout (like session access, modules, or services consulted on the spot). A good way to handle this is by *pushing these out of the method* or function the code resides in, so they come in through the method’s parameters. That way, you make that bit of code **self-contained** and it becomes possible to move it around or split it up further.

如果不是因为散布在各处的无数**依赖关系** (例如，会话访问，模块或当场咨询的服务)，代码通常是可以接受的。 解决*这些问题的*一个好方法是*将这些*代码从代码所驻留*的方法*或函数中推出，以便它们通过方法的参数进入。 这样，您就可以使那段代码成为**独立**的代码，并且可以四处移动或进一步拆分。

And once code is self-contained, **you can test it**.

一旦代码自成体系， **就可以对其进行测试** 。

## 建立信心：测试 **(**Building Confidence: Testing**)** ##

A violent ogre roaming through the mud can do more damage than a violent ogre in chains. A great way to gain some control over your system is trying to put chains on the parts that are **most critical** and thus potentially cause the **most damage** — tests, preferably automated, that run on every build.

在泥泞中漫游的食人魔比链中的食人魔造成的伤害更大。 获得对系统的控制权的一种好方法是尝试将链条放在**最关键**的部件上，从而可能造成**最大的损坏** \-在每个版本上运行的测试(最好是自动化的测试)。

![chain][]

The more automated tests you have to check the behavior of the system, the more **confidence** you can have when changing things. Because, if anything breaks, your tests will tell you something is wrong so you can fix it before the problem makes it to the **production environment**.

检查系统行为的自动化测试越多，进行更改时就越有**信心** 。 因为，如果发生任何故障，您的测试将告诉您有什么问题，因此您可以在问题产生到**生产环境**之前进行修复。

### 高级测试 **(**High-level tests**)** ###

One way to start testing your system is by adding **acceptance tests for critical scenarios** within your system. For an average e-commerce system, this would definitely include the checkout process: if no orders come in, you lose money. If orders come in but there’s a problem processing them, that’s something you can recover from without any customer noticing. With tests like that in place, you can protect yourself from unwittingly introducing major problems.

开始测试系统的一种方法是添加**针对**系统内**关键方案的验收测试** 。 对于普通的电子商务系统，这肯定会包括结帐流程：如果没有订单进来，您就亏本。 如果收到订单，但是在处理订单时出现问题，您可以在没有任何客户注意的情况下从中恢复。 有了这样的测试，您就可以防止自己在不知不觉中引入重大问题的情况。

### 低级测试 **(**Low-level tests**)** ###

On a **lower level**, you can apply [unit tests][]. Using the small steps approach of pushing dependencies out of your methods one by one, the result will be code that has a **clear input and a clear output**. In this situation, it becomes possible to cover the functionality of that code using unit tests. You define a set of inputs and declare the outputs you expect your code to produce, and your test suite will *make sure that bit of code keeps behaving as expected*.

在**较低级别** ，您可以应用[单元测试][unit tests] 。 使用逐步将依赖项逐个从方法中移出的依赖关系的小步骤方法，结果将是具有**清晰输入和清晰输出的代码** 。 在这种情况下，可以使用单元测试覆盖该代码的功能。 您定义了一组输入并声明了您希望代码产生的输出，并且测试套件将*确保代码的一部分保持预期的状态* 。

### 不要测试一切 **(**Don’t test everything**)** ###

Testing every single line of code in a system is both economically unviable and unnecessary. In principle, it would be great to be perfectly confident about every aspect of your system, but the cost of making everything testable, writing tests and maintaining the tests will start to outweigh the benefits at some point. In my experience, your time is best spent writing **tests for non-trivial business logic and parts of the system that would cause havoc should they malfunction** (even if the code is actually simple).

测试系统中的每一行代码在经济上都是不可行的，而且没有必要。 原则上，对系统的各个方面都完全有信心是很高兴的，但是使一切都可测试，编写测试和维护测试的成本有时会超过其收益。 以我的经验，您最好花时间**为非平凡的业务逻辑和系统部分**编写**测试，以防**万一**它们发生故障** (即使代码实际上很简单) **，也可能造成破坏** 。

In this way, you get the most dangerous monsters in chains and the swamp will be a safer, more predictable place for it.

这样，您就可以将最危险的怪物束缚起来，沼泽将是一个更安全，更可预测的地方。

## 隔离并更换 **(**Isolate and Replace**)** ##

A useful technique that combines pretty much all of the strategic patterns listed above is the old ‘isolate-and-replace’.

结合了上面列出的几乎所有战略模式的有用技术是旧的“隔离和替换”。

Every once in a while, you will come across some code that is just intangible in its internal workings and effects to be properly small-steps refactored within polynomial time. In a case like this, consider the following approach:

偶尔，您会遇到一些在内部工作和效果上无形的代码，这些代码在多项式时间内可以适当地重构。 在这种情况下，请考虑以下方法：

*  **Isolate the messy part**, drop it in a separate method or class.
    
    **隔离混乱的部分** ，将其放入单独的方法或类中。
 *  **Push out dependencies** so they come in as parameters.
    
    **推出依赖项，**以便它们作为参数进入。
 *  **Split logic from side-effects** (like saving to a DB) using a small-steps approach.
    
    使用小步骤方法将**逻辑从副作用** (例如保存到数据库)中分离出来。
 *  **Isolate the logic** in a separate method.
    
    用单独的方法**隔离逻辑** 。
 *  **Add unit tests** that cover the behavior of the logic.
    
    **添加**涵盖逻辑行为的**单元测试** 。
 *  **Rewrite the logic** from scratch. If it passes the tests, it should at least be close to the behavior displayed by the old version.
    
    从头开始**重写逻辑** 。 如果它通过测试，则至少应接近旧版本显示的行为。
 *  **Run old and new version of the logic side by side** in the production environment. The old version is still the one actually used.
    
    在生产环境中**并行运行新旧版本的逻辑** 。 旧版本仍然是实际使用的版本。
 *  **Log differences** in output between the new and the old version.
    
    **记录**新版本和旧版本之间的输出差异。
 *  **Monitor the logs** diligently. Whenever a difference shows up, add a new unit test for that case and fix the new version to pass the new case.
    
    认真**监视日志** 。 只要出现差异，就为该案例添加一个新的单元测试，并修复新版本以通过新案例。
 *  Repeat until old and new version **consistently agree** with each other.
    
    重复直到新旧版本**始终保持一致** 。
 *  **Switch the old version of the logic with the new version** with confidence.
    
    **请**放心**将逻辑的旧版本与新版本切换** 。

This technique allows you to swap a car’s motor without the car breaking down or it even noticing it had its internals replaced.

这项技术使您可以在不发生故障的情况下更换汽车的电动机，甚至不会注意到汽车内部已被更换。

## 说服自己 **(**Persuading Yourself**)** ##

The mindset and tools outlined above have proven, to me, to be a successful way of steering a system on the brink of collapse away from disaster.

对我来说，以上概述的思想和工具已被证明是引导系统濒临崩溃的边缘而摆脱灾难的成功方法。

![dragon yin yang][]

Where initially I was hesitant of dedicating my efforts full time to the task of taking on a long-term legacy challenge, I now see the many ways in which it has contributed to me **becoming a better developer**:

最初，我犹豫要全职投入长期的传统挑战，现在，我看到了许多有助于我**成为更好的开发人员的方式** ：

*  **Learning to recognize bad code**: you learn to see what’s bad because it’s what you have to spend most time on. The patterns you see here will not trip you up when you work on a new project because you know how it will hurt you in the future.
    
    **学会识别不良代码** ：您将学习到不良之处，因为这是您必须花费大量时间的时间。 当您从事新项目时，此处看到的模式不会使您失望，因为您知道将来会如何伤害您。
 *  **Back to basics**: in my case, every single aspect of the system had to be questioned and re-evaluated. Nothing is holy, and you get an appreciation for lots of issues modern day frameworks handle for you.
    
    **回到基础** ：以我为例，必须对系统的每个方面进行质疑和重新评估。 没有什么是圣洁的，您会对现代框架为您解决的许多问题感到赞赏。
 *  **You evolve with the system**: you see new challenges arise as the system in your care grows. This way you learn which bottlenecks you need to deal with as more and more people use your work and you need to scale up to stay on top of things.
    
    **您将随着系统的发展而变化** ：随着您所护理系统的**不断发展，**您会看到新的挑战。 通过这种方式，您可以了解随着越来越多的人使用您的工作而需要处理哪些瓶颈，并且需要扩大规模以掌握最新情况。
 *  **People are generating shiny new legacy constantly**: diligently, faster than they generate garbage belts in our oceans, knowing how to make it work is a good skill to have.
    
    **人们不断**地**创造出闪亮的新遗产** ：与他们在我们的海洋中产生垃圾带的努力相比，勤奋地工作要快得多，知道如何使其发挥作用是一项好技能。
 *  **Fun and rewarding**: especially looking back on a road well traveled and realizing the system you have today looks nothing like the system you first met years ago induces a real sense of accomplishment.
    
    **娱乐和回报** ：尤其是回头路途顺畅，认识到您今天拥有的系统似乎并不像您几年前首次遇到的系统带来真正的成就感。

![meadow cow][]

### 结束大量(或至少是冗长的)帖子 **(**To bring this substantial (or lengthy, at least) post to a close**)** ###

You can be the frightened peasant tiptoeing through the swamp, hoping somebody will come find you and take you to Disneyland instead, or you can take matters into your own hands, act like you own the place and enforce your own rules. Any swamp has solid ground underneath, and you can find it.

您可以是饱受惊吓的农民，在沼泽中tip脚，希望有人能找到您，然后带您到迪士尼乐园，或者您可以把事情掌握在自己手中，像您自己的地方一样，执行自己的规则。 任何沼泽下面都有坚固的地面，您可以找到它。

*Epilogue:*

*结语：*

*A few years later, you stroll through the meadow. On the horizon you can see the duke replacing the old ‘Here Be Dragons’ sign with a beer commercial.*

*几年后，您漫步在草地上。* *在地平线上，您会看到公爵用啤酒广告取代了旧的“ Here Be Dragons”标志。*

*He’s got a huge grin on his face.*

*他满脸笑容。*

> 翻译自: [https://www.sitepoint.com/technical-debt-rescuing-legacy-code-through-refactoring/][https_www.sitepoint.com_technical-debt-rescuing-legacy-code-through-refactoring]

重构：改善既有代码的设计

[intracto]: http://marketing.intracto.com/paying-technical-debt-how-to-rescue-legacy-code-through-refactoring
[Murky forest]: /images/20221123/49f7e58415104119952051e77bfcb4db.png
[Technical Debt]: https://www.youtube.com/watch?v=pqeJFYwnkjE
[party swamp color]: /images/20221123/43271f62fe5849878478c88d03152f34.png
[refactoring]: http://martinfowler.com/books/refactoring.html
[mayhem]: /images/20221123/1dcfe911369b44edae8ad5617c2b053a.png
[caution]: /images/20221123/3e941fd4e3b540dfbd4e7a9ad405b782.png
[errors]: /images/20221123/8e463192f1564a8880187500b6852cf3.png
[perfect meadow]: /images/20221123/57f250a35ab04e0ebdf2c765cdc7ee61.png
[swamp camping]: /images/20221123/73637f7b6e764a03ab897ae0b3ebf880.png
[Boy Scout rule]: http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule
[library]: /images/20221123/2c053d9b28674934a07ef9cfd644694a.png
[chain]: /images/20221123/3db1fec9f352412db609511d883670e0.png
[unit tests]: http://martinfowler.com/bliki/UnitTest.html
[dragon yin yang]: /images/20221123/f201029b8e6e49e5bd575c9ece716336.png
[meadow cow]: /images/20221123/309d012323f84b40938d7d3787824c88.png
[https_www.sitepoint.com_technical-debt-rescuing-legacy-code-through-refactoring]: https://www.sitepoint.com/technical-debt-rescuing-legacy-code-through-refactoring/