I’m by no means the first person to write about the dangers of rewriting code.  The definitive work for me is “Things You Should Never Do, Part I” written by Joel Spolsky in 2000.  If you haven’t read that, you should.
我绝不是第一个写重写代码危害的人。对我而言权威著作是 Joel Spolsky 在 2000 年写的"你永远不该做的事情,第一部分"。如果你还没读过,你应该读一读。

A recent discussion caused me to create a series of charts to graphically illustrate the dangers of rewriting.  I tend to think graphically – blame too much time in Powerpoint creating VC pitch decks.
最近的一次讨论促使我制作了一系列图表，直观地说明重写的危险性。我倾向于以图形的方式思考 —— 责怪我在 Powerpoint 中花了太多时间制作 VC 投资路演幻灯片。

I hope these charts help anyone considering rewriting code or being hectored by earnest, bright, young engineers and architects advocating a rewrite.  I’ve seen this movie before and I know how it ends.
我希望这些图表可以帮助到任何考虑重写代码，或是被热心、聪明、年轻的工程师和架构师劝说重写的人。我之前看过这部电影，我知道它的结局。

The Status Quo 现状

Firstly, here’s the status quo:
首先，这是现状：

The more time and money you spend on an existing product, generally speaking, the more functionality you get.
一般来说，您在现有产品上花费的时间和金钱越多，获得的功能就越多。

Let’s then overlay the competitiveness of the product in its target market.  Of course, what you want to achieve is a continual improvement in the competitiveness of the product.  Competitiveness doesn’t increase as fast as functionality.  Your competitors don’t stand still so, typically, the best you can hope for is to increase competitiveness gradually over time – even staying flat is a big challenge.
让我们再来看看产品在目标市场中的竞争力。当然，您想要实现的是产品竞争力的持续提升。竞争力的提升速度没有功能快。您的竞争对手不会止步不前，所以通常情况下，您能期望的最好结果就是竞争力随着时间的推移而逐步提高 —— 即使保持不变也是一个巨大的挑战。

Of course, this chart is idealized – functionality will increase in a more lumpy way as you release major new chunks of functionality and competitiveness will move up and down against your market. However, they demonstrate the point.
当然，这个图表是理想化的 —— 随着您发布重要的新功能块，功能会以更多的块状方式增加，竞争力也会在您的市场中上下波动。但是，它们证明了这一点。

Note:  the Y axis on all these charts represents “functionality” which, for the purposes of this discussion, can be considered a blend of features and quality.  The distinction between the two is not really important in this analysis since you always want to be advancing on one or both and they both impact overall product competitiveness.
注意：所有这些图表中的 Y 轴代表"功能"，就本次讨论而言，可以将其视为特性和质量的结合。两者之间的区别在于本分析并不十分重要，因为您总是希望在其中一个或两个方面取得进展，它们都会影响整体的产品竞争力。

Let’s Rewrite! 让我们重写吧！

Cue your software architect.  He’s just been reading about this great new application framework and language called Ban.an.as – it’s so much better than the way you’ve been doing things previously. Hell, Ban.an.as has built-in back-hashed inline quadroople integration comprehensions. Plus, all the cool kids are using it.
提示您的软件架构师。他刚刚阅读了一个名为 Ban.an.as 的优秀新应用框架和语言 —— 它比您以前的做事方式好得多。天哪，Ban.an.as 内置了后散列内联四倍集成理解。此外，所有酷小孩都在使用它。

If you’re a non-technical manager or executive, this can become quickly overwhelming and hard to argue against.  They’re the experts, right, so they must know what they’re talking about.
如果您是非技术经理或高管，这可能很快让人不知所措，难以辩驳。他们是专家，对吧，所以他们肯定知道自己在说什么。

[By the way, if you’re a non-engineer, there’s no such thing as “back-hashed inline quadroople integration comprehensions” – I made that up.  Sorry.
[顺便说一句，如果您不是工程师，没有所谓的"后散列内联四倍集成理解" —— 我编造了这个。抱歉。
A little secret here: there really haven’t been any new programming paradigms invented since the 1970s.  Software folks are generally in their 20s and didn’t see them the first time around – they just get “re-discovered” and given new names. Sssh – don’t tell anyone.]
这里有一个小秘密：自从 1970 年代以来，没有真正发明任何新的编程范式。软件人员通常 20 多岁，第一次看到它们的时候没看见 —— 它们只是被"重新发现"并被赋予新的名字。嘘 —— 不要告诉任何人。]

Just to be clear – I’m not saying that new languages, frameworks and technologies can’t create significant improvements in developer productivity – they can.  But, their introduction into an existing product has a big price, as we’ll see.
我要澄清一点 —— 我并不是说新的语言、框架和技术不能显著提高开发人员的生产力 —— 它们可以。但是，正如我们将看到的，将它们引入现有产品需要付出很大的代价。

Lastly, lest I alienate or offend my fellow geeks, I have been that very software architect advocating for the rewrite.  I learned this the hard way.
最后，为了不疏远或冒犯我的极客同仁，我一直是那个提倡重写的软件架构师。我从中艰难地学到了这一点。

So, this is how the rewrite is supposed to work in theory:
所以，理论上重写应该是这样工作的：

Let’s break this down:
让我们来分析一下：

The rework is expected to take some amount of time.  During this time, functionality won’t increase because developers are focusing on rebuilding the foundations.
重构预计需要一定的时间。在此期间，功能不会增加，因为开发人员专注于重建基础。
In the graph, that’s the blue area you can see peeking through.  That blue area represents the cost of the rewrite.
在图表中，你可以看到透出的蓝色区域。这片蓝色区域代表了重写的成本。

But, once the rewrite is done, the idea is that progress will be massively greater than it was previously because the new technology used is inherently better than the old.  Developers will be more productive with the new.  There’s no need to work with the old spaghetti code – instead, there’s a beautiful new architecture free of all the baggage that came before.
但是，一旦重写完成，进展将比之前大大加快，因为新使用的技术本质上优于旧技术。开发人员将在新环境下更有效率。不再需要处理旧的意大利面条式代码，取而代之的是一个摆脱了之前所有包袱的全新美观架构。

The critical point in time is the break-even point – this is the point at which the functionality of your product starts to exceed where you would have been had you stuck with the original implementation and continued working on it.
关键时间点是盈亏平衡点，这是你的产品功能开始超越原有实现并继续努力的时候。

During the rewrite period, the competitiveness of your product will typically decline since your competitors are not standing still and you can’t develop new functionality.
在重写期间，你的产品竞争力通常会下降，因为你的竞争对手并没有停滞不前，而你无法开发新功能。

However, the claim typically made by the rewrite advocates is that the rework will be relatively easy, take a relatively short period of time and hence achieve break-even quickly, after which it’s non-stop to the moon…
然而，重写的支持者通常声称，重构相对容易，只需相对较短的时间，因此可以快速实现盈亏平衡，之后就一路飙升...

What tends to go wrong – Part 1
哪里容易出错 - 第一部分

So, what tends to go wrong?  The most common problem is arguably the most common problem in software development generally; the rewrite takes significantly longer that expected.
那么，哪里最容易出错？最常见的问题可以说是软件开发中最普遍的问题：重写花费的时间比预期的要长得多。

There’s a discussion of why this tends to happen below but, for now, trust me that this often happens – if you’ve had any experience with software development at all, it’s highly likely that you’ve seen this happen too.
下面会讨论为什么会这样，但现在请相信我，这种情况经常发生——如果你有任何软件开发经验，很可能你也见过这种情况。

The result is that the cost of your rewrite is significantly larger than originally claimed.  (The blue area showing through on the chart is now much larger.)  This means that the break-even point is also significantly pushed back in time.
结果是，你的重写成本比最初声称的要大得多。（图表中透出的蓝色区域现在大了很多。）这意味着盈亏平衡点也大大推迟了。

The knock-on effect is that the competitiveness of your product drops for a much longer period of time.
连锁反应是，你的产品竞争力在更长的时间内下降。

If you are a big company, you can probably (hopefully) absorb the pushed out break-even point – maybe other products provide revenue, maybe good channel relationships continue to deliver sales of your product even though it’s falling versus the competition or maybe you’ve simply got lots of cash reserves.  Joel Spolsky references several big company rewrites that failed but did not kill the company.
如果你是一家大公司，你可能（希望）能够吸收延迟的盈亏平衡点——也许其他产品提供了收入，也许良好的渠道关系继续带来产品销售，尽管与竞争对手相比正在下降，或者你只是有大量现金储备。Joel Spolsky 提到了几个大公司的重写失败案例，但没有导致公司倒闭。

However, if you are a startup or smaller company (or even a less fortunate bigger company), this can be – some might argue, is very likely to be – fatal.
然而，如果你是一家初创公司或小公司（甚至是一家不太幸运的大公司），这可能是——有人可能会说，很可能是——致命的。

What tends to go wrong – Part 2
哪里容易出错 - 第二部分

It gets worse. 情况变得更糟。

Not only does the rewrite often take longer than expected but functionality is not even flat at the end of it – functionality is actually lost as a side-effect of the rewrite.
重写不仅经常比预期花费更长时间，而且功能在重写结束时甚至没有达到原有水平——实际上，作为重写的副作用，一些功能反而丢失了。

That’s because all of those small but important features, tweaks and bug-fixes that were in the original product don’t get reimplemented during the rewrite.  (These are the “hairs” that Joel discusses.)
这是因为在重写过程中，原有产品中那些小但重要的功能、优化和错误修复并没有被重新实现。（这些就是 Joel 所说的"毛发"。）

Remember that the main focus of the rewrite in the developer/architect’s mind is generally to build a better architecture and these small features don’t seem important and mess up this beautiful new architecture.
请记住，在开发人员/架构师看来，重写的主要重点通常是构建更好的架构，而这些小功能看起来并不重要，还会破坏这个漂亮的新架构。

Plus, however good the developers are, they will introduce new bugs that will only get exposed and fixed through usage.
另外，无论开发人员有多优秀，他们都会引入新的错误，而这些错误只有通过使用才能暴露和修复。

The net result is that the product after the rewrite is, in the eyes of the end-user and the market, worse than the product before the rewrite, even if it’s better in the eyes of the developer.
最终的结果是，在最终用户和市场看来，重写后的产品比重写前的产品更糟，即使在开发人员眼中它变得更好。

This further pushes out the break-even point in terms of functionality and competitiveness of your product will take a long time to recover.  If you listen carefully, you can probably hear your competitors wetting themselves laughing at your folly.
这进一步推迟了产品在功能和竞争力方面的收支平衡点，你的产品将需要很长时间才能恢复。如果仔细听，你可能会听到竞争对手正为你的愚蠢行为而窃笑。

What tends to go wrong – Part 3
哪里容易出错 - 第三部分

Oh dear. 天哪。

The nail in the coffin is that, not only does the rewrite take longer than expected, and functionality get lost in the process, but the benefits of the new technology/language/framework turn out to not be nearly as great as claimed.  Meanwhile, if you’d stuck with the status quo, you would have got more productive due to normal learning effects – i.e. don’t forget that while your team is climbing the learning curve with the new technology, you would have been getting better with the old one anyway.
致命的是，重写不仅比预期花费更长时间，功能在此过程中丢失，而且新技术/语言/框架带来的好处远没有宣传的那么大。与此同时，如果你坚持现状，由于正常的学习效果，你本可以变得更有生产力——即不要忘记，当你的团队正在学习新技术时，你无论如何都会在旧技术上变得更好。

Any one of the 3 problems above is potentially fatal but all 3 together is definitely so.  Competitiveness of your product will likely never recover.
上述任何一个问题都可能是致命的，但三个问题加在一起肯定是致命的。你的产品的竞争力可能永远无法恢复。

Why does this happen?
为什么会发生这种情况？

So, the above sections discuss what can go wrong.  It might help to understand why this happens.
以上部分讨论了可能出错的地方。了解为什么会发生这种情况可能会有所帮助。

In Joel’s seminal post cited above, he makes the point, “It’s harder to read code than to write it.”
在上面引用的 Joel 的开创性文章中，他指出："阅读代码比编写代码更难。"

Very true – it’s also more fun to write new code than learn someone else’s code.
非常正确——编写新代码也比学习别人的代码更有趣。

Developers like to feel smart and, intellectually, learning someone else’s code can seem like a lose-lose scenario to a lot of developers – if the code is bad, it’s painful to learn and you’re going to have to fix it.  On the other hand, if it’s better than you would have written, it’s going to make you feel stupid.
开发人员喜欢感到聪明，但从智力上讲，对许多开发人员来说，学习别人的代码似乎是一个双输的场景——如果代码很糟糕，学习起来很痛苦，你还得修复它。另一方面，如果它比你写的更好，会让你觉得自己很蠢。

Also, bear in mind that the fundamental motivation of most (not all) engineers is to Learn New Stuff ™.  They are always going to gravitate towards new things over old problems they feel they’ve already solved.  Again, I’m not faulting developers for this – it doesn’t make them bad people but, if you’re a non-developer, it’s critical you understand this motivation.
另外，请记住，大多数（不是全部）工程师的根本动机是学习新东西™。他们总是倾向于新事物，而不是他们认为已经解决的旧问题。再次强调，我并不是在指责开发人员——这并不会使他们成为坏人，但是，如果你不是开发人员，理解这种动机对你来说至关重要。

Put it this way: would you rather be the guy that architected the Golden Gate Bridge or one of the guys hanging off it on a rope, scraping off rust and repainting it?
这样看吧:你是愿意成为设计金门大桥的人,还是愿意成为那些悬挂在桥上,用绳子刮除锈迹、重新油漆的人之一?

Another problem is that when you rewrite, you typically make rapid progress early on which gives false validation to the decision to rewrite.  It makes you feel smart – what a beautiful cathedral I’m building.
另一个问题是,当你重写时,通常会在早期取得快速进展,这给重写的决定提供了错误的验证。这会让你感觉很聪明——我正在建造一座多么漂亮的大教堂啊。

That’s because you’re writing code in a vacuum.  No one is using the code yet; certainly no actual users.  But, as you start to reach launch date, all those small features, tweaks and bug-fixes – all that learning that was encapsulated in your old product – starts to become conspicuous by its absence.
那是因为你在真空中编写代码。还没有人在使用这些代码;当然也没有实际的用户。但是,当你开始接近发布日期时,所有那些小功能、调整和错误修复——所有封装在旧产品中的学习成果——由于缺失而变得引人注目。

The bottom-line is that, when the case to rewrite is being made, it is not comparing apples to apples – it is comparing theoretical benefits with actual benefits.  The actual benefit in question being, of course, that you have an existing product that works.
底线是,当提出重写的理由时,它不是在比较苹果和苹果——它是在比较理论收益和实际收益。当然,这里的实际收益是,你有一个现成的、可以工作的产品。

Comparing the pros and cons of writing a new application in language A versus B is not the same as comparing an application already written in language A versus rewriting that application in language B.  Why?  because any productivity gains of one language over the other are typically massively overridden by the loss of all the domain knowledge, testing and fixes encapsulated in the existing product.
比较用语言 A 和 B 编写新应用程序的利弊,与比较已经用语言 A 编写的应用程序和用语言 B 重写该应用程序是不同的。为什么?因为一种语言相对于另一种语言的任何生产力提升,通常会被现有产品中封装的所有领域知识、测试和修复的损失所大大抵消。

Should you EVER rewrite?
你应该重写吗?

So, are there ever circumstances when you should rewrite?  My answer here is an emphatic“maybe”.
那么,有没有应该重写的情况?我在这里的回答是一个强调的"也许"。

Let’s consider some of the possible situations:
让我们考虑一些可能的情况:

1.  An irretrievably sick code-base
1. 一个无可救药的病态代码库
The symptom here is that it takes exponentially longer to add each new feature – per the chart above.  Another symptom is that defect reports continue to come in as fast, or faster than you can fix them – you’re treading water.
这里的症状是,添加每个新功能需要指数级更长的时间——根据上面的图表。另一个症状是,缺陷报告持续以与你修复它们一样快或更快的速度出现——你正在踩水。
However, an irretrievably sick development team is a much more likely culprit than an irretrievably sick product.
然而,一个无可救药的病态开发团队比一个无可救药的病态产品更有可能是罪魁祸首。
Don’t let developers convince you that they can’t maintain a codebase – what they most often mean is that they don’t want to maintain a codebase.
不要让开发人员说服你,他们无法维护代码库——他们最常说的是,他们不想维护代码库。

2.  The developers who wrote the code are not available
2. 编写代码的开发人员无法使用
If you buy/find/inherit a codebase, make sure you have access to as many of the developers who wrote it as possible, for as long as possible.  If you didn’t…doh!
如果你购买/找到/继承了一个代码库,请确保你能够尽可能长时间地访问尽可能多的编写它的开发人员。如果你没有……哎呀!
Again, don’t fall into the trap – developers will always prefer to write new code of their own than learn how the existing code works.
再次,不要掉入陷阱——开发人员总是更愿意编写自己的新代码,而不是学习现有代码的工作原理。

3.  A genuine change to a new problem domain
3. 真正转向新的问题领域
Sometimes, some of the fundamental assumptions and technology choices may no longer be valid for the problem domain that your product is addressing.  But, then I’d argue, you’re really talking about building a new product rather than rewriting an existing one.
有时，针对产品所处领域的某些基本假设和技术选择可能不再有效。但我要说，这实际上是在讨论开发新产品，而不是重写现有产品。

4. Fundamentally incorrect or limiting technology choices
4. 从根本上错误或限制性的技术选择
In some cases, the team that originally built the product may have made some poor choices in the technologies to use or the approaches to take.  They may simply not map well to the problem domain of your product.  However, in my experience, this is true much less often than developers claim it’s true.
在某些情况下，最初构建产品的团队在所使用的技术或采取的方法上可能做出了一些糟糕的选择。它们可能与产品的问题领域不太匹配。然而，根据我的经验，实际情况远没有开发人员声称的那么频繁。
Also, there are points where you start to hit fundamental scalability limits of certain technologies.  However, keep in mind that if you’re hitting those scalability limits, someone else probably has too before you, and solutions to the problem exist.
此外，在某些时候，你会开始触及某些技术的基本可扩展性限制。但是请记住，如果你遇到了这些可扩展性限制，在你之前可能已经有其他人遇到了，而且这个问题的解决方案是存在的。

So, if you are even entertaining the suggestion of a rewrite, make sure you get the developers to give you a specific cost-benefit analysis of the rewrite.  Show them the charts above and get them to tell you why these problems won’t occur in this case, even though they occur in almost every case.
因此，如果你甚至在考虑重写的建议，一定要让开发人员给你一个具体的重写成本效益分析。向他们展示上面的图表，让他们告诉你为什么在这种情况下不会发生这些问题，尽管它们几乎在每种情况下都会发生。

If and when you are convinced that this is one of those rare situations where a rewrite is the right approach, you need to make it surgical:  where will you make the incision?  How deep do you cut?  What are the risks?  What are the potential side-effects?  How can I make sure no functionality is lost? How can it be done incrementally?
如果你确信这是少数需要重写的情况之一，你需要谨慎行事：你会在哪里动手术？切口有多深？有什么风险？有什么潜在的副作用？我如何确保不会丢失功能？如何逐步完成？

Divide the rewrite into a series of smaller changes, during which functionality absolutely cannot be lost.  Rewrite parts of the system at a time with a well defined, understood and testable interface between old and new.
将重写分解为一系列较小的更改，在此过程中绝对不能丢失功能。一次重写系统的一部分，在新旧之间有一个定义良好、易于理解和可测试的接口。

Better still, don’t rewrite.
更好的办法是，不要重写。

Good luck. 祝你好运。

Agree, disagree?  Please leave a comment.
同意还是不同意？请留下评论。