作者 | Herb Caudill
译者 | 无明
生存，还是去世亡，这是一个问题。重写，还是不重写，这是导致生存或去世亡的另一个问题。
这是一个很老套的问题：你该当重写运用程序吗？又或者这是“任何一家软件公司都会犯的一个计策性缺点”？或许，对付一个已经很成熟的代码库来说，这并不是一个二选一的问题。
大约 20 年前，Joel Spolsky 在他的文章“Things You Should Never Do”中对网景公司重写 Netscape 代码库的行为进行了一番痛斥。
他认为，永久不要重写功能性运用程序，由于：
运用程序代码库中那些看起来很粗糙的部分常日包含了与各种边界用例和奇怪 bug 干系的信息，而这些信息常日是得之不易的。重写运用程序是一项非常耗时的事情，它不仅无法让你改进现有的产品，而且在此期间，竞争对手可能借机向你逼近。对付大多数人来说，Jole 的不雅观点成为了某种信条。我也承认，那个时候我在很大程度上也受到了他的不雅观点的影响。
在接下来的几年，我听到了一些不同的不雅观点。这些不雅观点认为，在某些情形下，重写运用程序也是故意义的。例如：
有时候，遗留代码库确实混乱到无法理清楚，纵然是最大略的变更也须要对代码的其他部分进行级联变更。最初的技能选型可能会阻碍你改进系统。最初的技能可能已经由时，招聘高质量的开拓职员变得很困难（或者本钱很高）。当然，精确的答案是，这在很大程度上取决于实际情形。有时候逐步重构遗留代码会更故意义，而有时候把旧代码扔掉并重新开始会更故意义。
但这并不是唯一的选择。让我们来看看下面的六个故事，看看能够从中吸取到什么教训。
1. Netscape
Netscape Navigator 最早是在 1994 年发布的，在发布不到两年之后，网景公司以 30 亿美元的 IPO 开启了互联网时期。
Netscape 的第一个真正竞争对手是微软于 1996 年推出的 IE 浏览器。
1998 年初，Netscape 仍旧是领先的浏览器，但只是勉强领先。Netscape 的零售价为 49 美元，而微软免费赠予 IE，并将其作为默认浏览器与 Windows 一起发布。
在发布 Netscape 4.0 之后，网景公司宣告将免费供应 5.0 版本，并由公司帮助的一个叫作 Mozilla 的开源社区卖力开拓。
这在当时基本上是亘古未有的，网景公司由于这个大胆的举动赢得了人们的尊重。然而，社区并没有真正兑现之前的承若。Jamie Zawinski 是该浏览器最早的开拓者之一，他阐明说：
事实上，由于 Mozilla 项目的贡献者包括大约 100 名全职 Netscape 开拓职员和大约 30 名外部兼职开拓职员，以是这个项目实际上仍旧完备属于网景。
该团队得出的结论是，外部开拓职员之以是对这个开源项目不感兴趣，是由于现有的代码库太乱了：
代码太繁芜，太粗糙，难以修正，人们乃至无法添加新代码，这也便是为什么我们要切换到新的代码库。从理论上讲，一个更干净的新代码库更随意马虎让人们理解，也更随意马虎让他们贡献代码。
从头开始
一年后，这个小组决定放弃 5.0 版本，并从头开始开拓 6.0 版本。
又过了两年，Netscape 6.0 终于发布了。但纵然经由了这么永劫光，它仍旧没有为发布做好准备。《纽约时报》评论员 David Pogue 说，光是启动就要花一分钟韶光，不仅占用了很大的内存，而且短缺前几代浏览器的一些大略功能。
但这些还不是最主要的。在 Netscape 结束不前的三年中，IE 已经抢占了所有剩余的市场份额。
1999 年，当重写事情还在进行当中的时候，AOL 以 100 亿美元的价格收购了网景公司。
在 Netscape 6.0 发布两年之后，AOL 内部的 Netscape 团队就被终结了。
Mozilla 连续在 2002 年发布了 Firefox 浏览器——这又是又一次彻底的重写。不过 Firefox 确实设法从微软手中夺回了一些市场份额。
但作为一家企业，网景已经去世了。令工资难的是，在 2012 年与 AOL 达成一项协议后，微软终极拿走了网景剩余的知识产权。
在赢得这场战斗之后，微软减少了对浏览器技能的投入。IE 6.0 于 2001 年发布，此后 5 年没有再进行升级，一些人认为微软是故意这么做的，目的是阻挡 Web 平台的发展。
学到的教训
人们认为，从长远来看，重写并不一定是一场灾害，由于这个项目终极催生了 Gecko 引擎和 Firefox 浏览器。
但多年来，在等待新浏览器涌现的过程中，由于 IE6 无休止的垄断，我们不得不忍受 Web 技能的结束不前。但终极闭幕 IE6 时期的并不是 Firefox，而是谷歌 Chrome。
不管如何，现在的问题并不是说重写对 Web 是否有好处，而是从公司的角度来看这是不是一个好的决定。网景的衰落并不完备是由于重写——法院认为是微软滥用了他们的垄断地位。
但重写仍旧是一个匆匆成成分，终极的结果是毁掉了一家代价数十亿美元的公司，并裁员数千人。以是，我赞许 Joel 的不雅观点，这次重写的结果是灾害性的。
2. Basecamp2000 年代早期，芝加哥的一家名为 37signals 的网页设计公司由于其创始人 Jason Fried 和 David Heinemeier Hansson 的影响力而得到了一批追随者。
2004 年，他们开拓了一个供内部利用的项目管理工具，并将其作为一款 SaaS 做事对外发布，名为 Basecamp。
那个时候，订阅软件还是一个很新鲜的东西。项目管理工具被装在包装盒里，表面贴着四位数的价格标签，还有厚厚的手册，全都是关于如何建模关键路径和天生繁芜的甘特图。
Basecamp 的售价为每月 50 美元，它的界面超级大略，十分看重沟通效果，给人线人一新的觉得。
几年之后，Basecamp 的用户达到了 50 万，每月都有支票滚滚而来，但 Jason 和 David 开始感到焦躁不安。
几年前，我在软件行业大会上听到 David 讲述了这个故事。他说，他不仅相信 Joel Spolsky 所说的重写软件会毁掉公司，而且敏捷运动还引发了他的某种自以为是：
我完备被卓越软件的理念所吸引。那些代码是无限可塑的，遗留代码是代价令媛。你可以改变任何东西，任何软件，任何代码都可以重写。如果软件很难被修正，那是你的错。你是一个糟糕的程序员，你必须学会变得更好。
然而，在他所谓的“七个丰收年”之后，他们陷入了困境——而这统统与技能债务无关。
黄金手铐
他们开始创造自己的激情亲切开始在消退。他们不仅没有动力去开拓旗舰产品，就连他们自己也不怎么利用自己的产品。
他们有很多关于如何从根本上让产品变得更好的想法，但由于已经有成千上万的用户在 Basecamp 上构建了他们的事情流，他们所做出的每一个变更都会对很多人造成毁坏性影响。这个时候，给改变造成阻碍碍的不是粗糙的代码库，而是用户。
为了让现有的客户满意，他们即是是冻结了产品，无法吸引到新客户。这对公司来说不是一个迫不及待的问题，而是一个长期的威胁。
部分问题在于，你只能从现有的客户那里听到他们的心声，却无法从未来客户那里听到任何东西。
他们开始意识到，他们的产品成了一套黄金手铐。
他们开始重写 Basecamp，结果非常棒。他们花了大约一年的韶光，在 Basecamp 2 发布后，新注册用户立即翻了一番。
他们做了两件有趣的事，我认为这便是他们取获胜利的缘故原由。
首先，他们没有试图重修已有的产品，由于他们对要办理的问题有了新的想法。
他们把 Basecamp 2 作为一个全新的产品，而且不担保它能够向后兼容 Basecamp Classic。有很多东西是新的，有一些东西被去掉了，还有很多东西变得完备不一样。
这个决定给了他们一定程度的自由。自由是一种动力，而有动力的人会做得更多。
淘汰旧产品的危害
那么其他数十万现有用户该怎么办呢？由于动了他们的奶酪，以是他们怨声连天。
这就引出了他们做的第二件有趣的事请，他们并没有淘汰旧产品。
David 指出，如果你强制用户打包走人，就犯了“有史以来最严重的计策性缺点”：由于如果这样，这些用户就会考虑是连续利用你的软件还是干脆转移到别的地方去。
Basecamp 选择“尊重他们的遗留用户”：他们简化了用户的升级路径，而且不哀求他们一定要离开 Basecamp Classic。不仅如此，他们还承诺将连续无限期地支持和掩护 Basecamp Classic。
更令人感到惊喜的是，四年之后，他们又重头来过：他们在 2015 年发布了 Basecamp 3，这也是一个重写版本，删除了一些旧功能，添加了一些新功能，并且做出了很多改变。和以前一样，老版本用户可以轻松升级——但如果他们乐意，也可以连续利用 Basecamp Classic 或 Basecamp 2，“直到互联网结束的那一天”。
学到的教训
在我看来，这种模式非常具有启示性。
每一次重写都是在重新核阅 Basecamp 的设计决策，并让他们有机会构建之前希望构建的产品。
对付用户来说，不肯望发生改变的用户可以保持原地不动，而希望利用新功能的用户可以利用一个全新的、更好的、经由寻思熟虑的产品。
但无限期地掩护产品的多个版本并不是没有代价的，正如 David 说的那样：
这绝对不是免费的。你为什么会希望它是免费的呢？它实在很有代价，以是当然不是免费的，但这么做是值得的。
3. Visual Studio 和 VS Code微软开拓 VS Code 是为了吸引其他平台上的开拓者。
在很长一段韶光里，在微软的天下里事情就像是一个硬币的两面。如果你利用 Visual Studio，那么便是在做.NET 开拓。反过来，如果你做.NET 开拓，那一定在利用 Visual Studio。这将软件社区分成了两大相互排斥的阵营，对任何一方都不是很有利。
吸引墙外那些很酷的人才
纵然是在 Steve Ballmer 时期，这种情形就已经开始发生变革。还记得 ASP.NET 团队决定不再重新发明 jQuery 吗！
不管从哪一方面来看，Visual Studio 都是一个重量级的产品：安装它可能须要半个多小时。它必须支持企业客户所依赖的各种繁芜用例。因此，如果微软试图通过添加特性来吸引其他平台的开拓者，那么将 Visual Studio 作为出发点是毫无意义的。而且，开拓 Mac 或 Linux 版本的 Visual Studio 的想法也是不切实际的。
以是，微软从零开始，并且不担保向后兼容性。
实际上也并非完备从零开始：微软已经有一些现成的东西，比如 Monaco 编辑器。由于 VS Code 是一个 Node.js 运用程序（用 Typescript 开拓，运行在 Electronic 上），以是他们可以利用丰富的 JavaScript 生态系统。
VS Code 是一款开源、轻量级、快速和可扩展的编辑器，而且令人感到惊异的是，作为一款微软的产品，它已经成为很多开拓者的首选编程环境。
这两款产品都还在积极开拓中，而且没有迹象表明微软会打算停滞 Visual Studio 的开拓。
学到的教训
与 Netscape 形成光鲜的比拟，微软成功地环绕 VS Code 构建了一个生动的开源社区。
当然，并不是每家公司都会有一个可以完备支持开源其核心产品的业务模型。
但是，如果开源是公司开拓策略的一部分，那么就值得通过比较这两个案例找出微软做了哪些不一样的事情匆匆成了社区的繁荣。
其余，微软还为 VS Code 供应了一个可靠的扩展模型，社区已经开拓了近 10,000 个插件。
在过去几年里，事情发生了根本性的变革，软件的开拓和原型创建比以往任何时候都更随意马虎。
只管人们都对当今开拓工具集的繁芜性感到绝望，但事实是，JavaScript 生态系统在过去几年里已经发展成为人们期待已久的可重用、模块化的开源乐土。从这方面来看，这是一个亘古未有的时期。
4. Gmail 和 InboxGmail 的 Inbox 最初是作为 Gmail 的精简版 UX 引入的，“旨在关注真正主要的东西”。它从未具备与原始 Gmail 相同的功能，但引入了捆绑、固定电子邮件和待处理等新功能。
包括我在内的一些人对 Inbox 很感兴趣。我一贯以为 Inbox 是 Gmail 终极会成为的东西，以是忍受着它短缺 Gmail 的一些功能，并期望终极会在 Inbox 中增加这些功能。
两个界面，一个做事
Inbox 和 Gmail 都利用了相同的后端。它们实质上只是相同做事的不同用户界面，你可以随意来回切换。这既有好处也有坏处：如果 Inbox 短缺了某个功能（比如假期自动回答），你可以回到 Gmail 做你须要做的事情。但来回切换难免会以为有点奇怪。
然而，过了一段韶光，Inbox 停滞改进，而且很明显，谷歌不再为其投入任何资源。果真，在推出四年之后，谷歌宣告将关闭 Inbox。
我最初感到非常恼火，但在花了一点韶光研究了最新版本的 Gmail 之后，我创造 Inbox 中许多我最喜好的功能都被移植到了原始产品中：智能回答、悬停操作、内联附件和图像。Gmail 的多收件箱也是 Inbox 捆绑的一个很好的替代品。
但并非统统都很完美：例如，待处理已经成为很多人处理电子邮件的一个关键部分，Inbox 的消逝让他们感到无所适从。
学到的教训
Inbox 让 Gmail 团队可以在不中断事情流程的情形下，为那些不切换视图的绝大多数用户试验新功能。
然而，由于利用了相同的后端，Gmail 给自己的创新能力设置了严格的限定。
谷歌再次由于关闭了一项广受欢迎的做事而受到责怪。当然，关闭产品对谷歌来说已经是家常便饭了，我们还能期待什么呢！
在这个案例中，Inbox 让我们相信我们看到了 Gmail 的未来。这绝对不是一次完美的退出，很多人不得不重新利用旧产品，并且失落去了 Inbox 的创新，这是很糟糕的。
我认为，如果 Gmail 在关闭 Inbox 前就具备 Inbox 的所有功能，人们的烦懑或许就会少一些。
5. FogBugz 和 TrelloFogBugz 是一个特殊有趣的案例，由于它是 Joel Spolsky 的产品：它向我们展示了永不重写软件的原则如何表示在实际的产品中。
在 Jira 和 GitHub Issues 涌现之前，有一个基于 Web 的 bug 跟踪产品，叫作 FogBugz。它于 2000 年发布，是 Fog Creek 软件公司的第一款产品。这家公司是由 Joel 和 Michael Pryor 共同创办的，这款产品也是他们十多年来的一款旗舰级产品。他们最初只将其作为打包软件出售，可以安装在用户自己的做事器上，但后来又推出了一个托管的订阅版本。
它开始变得非常盛行，我的公司也用了它很多年。在当时，它是一款伟大的产品。
FogBugz 最初是用 ASP 开拓的，运行在 Windows 做事器上。在微软推出 ASP.NET 的时候，Joel 阐明了为什么他不焦急升级。
https://www.joelonsoftware.com/2002/04/11/our-net-strategy/
为了让人们能够在 Linux 做事器上安装 FogBugz，一名演习生开拓了一个叫作 Thistle 的编译器，将 ASP 转成 PHP。到了 2006 年，Thistle 发展成为一门私有的编程措辞，叫作 Wasabi，可以将代码编译成 ASP、PHP 和客户端 JavaScript。
一个迁移转变点
FogBugz 在 10 年的韶光里已经发展成一款成熟而稳定的产品。
但 FogBugz 并没有把天下点燃，反而显得有点老态龙钟。虽然 bug 跟踪系统的市场仍旧很分散，但 Atlassian 的 Jira——比 FogBugz 晚推出几年——已经成为大型企业用户的首选。
我对 Fog Creek 公司发展史上的这个迁移转变点感到非常好奇。和 Basecamp 一样，他们也有一款可以盈利的成熟产品。但它不再性感，可能也不怎么令人感到愉快。无论是好是坏，它都表示出了多年来技能的变革以及关于如何办理特定问题的想法演化。
当然，一种应对方法是像 Basecamp 那样：Fog Creek 可以利用学到的有关 bug 跟踪系统的所有知识来重新开拓 FogBugz，从头开始。
不过我猜这个想法并没有走得太远……
最近，我看到了 2009 年的一篇文章，当时 Joel 正在为 Inc 杂志撰写月度专栏。这个专栏叫作“缓慢增长是否即是缓慢去世亡？”，与他以往那种自傲的夸夸其会商然分歧：变成了一种自察、试探和疑惑。Atlassian 的快速增长让他感到担忧——他很想知道在 bug 追踪系统市场上，终极是否只会剩下一款产品。
以是他决定做两件事情。首先，将所有功能添加到 FogBugz 中。
第二，建立企业发卖团队。Joel 承认这不是他善于的事情，实在他很讨厌做这样的事情。
我不知道这两个操持的结果如何。Joel 末了一次在他的博客上提到 FogBugz 是几个月后的一个小版本发布声明。
新的希望
事情是这样的：
大约在 Fog Creek 软件公司成立 10 周年之际，我开始在想，如果我们想让员工在接下来的 10 年里保持愉快和动力，就须要做一些新的东西。
因此，他们把团队分成了两组，每个小组都要想出一个新的产品创意，并构建出原型。
得胜的想法受到了看板的启示。看板是一种物理工具，被用在软件开拓中，常日会在白板上粘贴便利贴，并在不同的栏位之间移动这些便利贴。
Joel 将其描述为一种用于管理更高等别的任务的工具。
在开拓 Trello 的过程中，Fog Creek 的开拓职员有机会利用新技能更换旧技能：
我们开始利用尖真个技能。常日，这意味着一定会割到自己的手指。我们的开拓职员在 MongoDB、WebSockets、CoffeeScript 和 Node 上鲜血满布，但至少他们玩得很愉快。如果你能让他们去开拓一款令人愉快的产品，他们会很愉快，也会对他们的事情充满热爱。
Trello 还启用了第三方插件，这成倍地增加了内部开拓团队的事情量。
当然，程序员们立时就看到了 Trello 的实用性，但是这个工具并没有任何特定于软件开拓的东西。很快，Trello 就成了一种通用的内容管理工具，被用来管理每周餐饮、婚礼活动和动物收容，等等。
FogBugz 是一款面向特定利基市场的垂直产品，而 Trello 是一款横向产品，任何人都可以用它做他们想做的事情。Joel 认为，对付 FogBugz 来说，在这个关键时候，“横向发展”是精确的：
开拓一款对付各行各业来说都有用的横向产品险些是不可能的。你不能收取太高的用度，由于你要与其他横向产品竞争，而这些产品可以通过大量用户来分放开辟本钱。这是高风险、高回报的，并不适宜年轻的初创企业。但对付像 Fog Creek 这样成熟稳定的公司来说，这是个不错的主张。
为了快速吸引更多的用户，Trello 最初是免费的，后来才推出了付费的“商业”版本。
2014 年，Trello 被分拆成一家独立的公司。三年后，拥有 1700 多万用户的 Trello 以 4.25 亿美元的价格把自己卖掉了。具有讽刺意味的是，买家竟然是 Fog Creek 的宿敌 Atlassian。
回归
Fog Creek 连续开拓另一款新产品，一个协作编程环境，最初叫作 HyperDev，后来改成 GoMix，末了又改名为 Glitch。
与此同时，FogBugz 失落去了昔日的光彩。2017 年，有人认为 FogBugz 这个名字太过平淡，于是他们努力将其重新命名为 Manuscript。一年后，Fog Creek 将 Manuscript 卖给了一家叫作 DevFactory 的小公司，这家公司立即又把名字改回 FogBugz。
在 CEO Anil Dash 的领导下，Fog Creek 成为一家只供应单一产品的公司，并更名为 Glitch。
学到的教训
这个故事的关键点在于，Fog Creek 关心如何为程序员赋能多过关心 bug 跟踪系统本身——从他们自己的程序员开始：
为程序员创造一个好的事情环境是我们的紧张目标。我们有私人办公室，出差坐头等舱，每周事情 40 小时，为员工买午餐、人体工学椅和顶级电脑。我们的公式是：伟大的事情条件造就伟大的程序员，伟大的程序员造就伟大的软件，伟大的软件为我们带来利润！
有了这个“公式”，我们就可以把这统统连成一个完全的故事：Fog Creek 为开拓者的幸福打造了一家企业，这可以从公司的产品和内部“操作系统”反响出来。
我认为，从 Joel 讲述 Trello 起源故事的办法来看，重点并不在于探求新的商业机会，而在于探求一种可以让 Fog Creek 的员工愉快事情的方法。创造一个代价 5 亿美元的产品只是一个令人愉快的意外结果。
但我还是忍不住为 FogBugz 的结局感到难过。我认为在产品的末了阶段不会有多少人会感到愉快。
很显然，所有人都有更主要的事情要做：Stack Overflow、Trello 和 Glitch 都比 FogBugz 更有用、更有代价。所有人的韶光都是有限的。因此，我不会由于任何人对 FogBugz 失落去兴趣而感到惋惜，由于 FogBugz 拥有 20 年历史的代码库和竞争激烈的利基市场。至少它的虔诚用户末了找到了一个安身之处，没有落得“日落西山”的了局！
但从情绪方面讲，我希望能够有一个更好的办法来“纪念”这些年来创造这个产品和利用这个产品的人。
6. FreshBooks 和 BillSpring2000 年代早期，Mike McDerment 拥有一家小型的设计公司。他认为司帐软件太过繁芜，以是就用 Word 和 Excel 来管理票据。
但终于有一天，这种办法不再见效了：
有一天，我欠妥心弄丢了一份主要的客户票据，这让我感到很崩溃。我知道肯定有更好的方法，以是接下来我花了两周韶光写了一些代码，这些代码为 FreshBooks 的出身奠定了根本。
Mike 是一位设计师，而不是程序员，但他和两位联合创始人设法拼凑出了一个足够好的工具，有人乐意每月花 10 美元利用它。他花了将近四年的韶光才把买卖做到让他有能力从父母的地下室搬出来。
在这款产品推出 10 周年之际（这听起来是不是有点耳熟？），FreshBooks 已经赚到了丰硕的利润，拥有 1000 多万用户和 300 多名员工。
但有一个问题：在他们开始雇佣“真正”的程序员之前，他们已经有一百万行“创始人写的代码”。一名外部分析师审查了他们的代码库，并得出结论：
“好是，你们已经办理了最困难的问题。你们已经知道如何创办一家企业，拥有一款人们喜好的产品。坏是，你们这些家伙的技能太烂了”。
更主要的是，他们有了一些新想法，但现有的产品无法实现这些想法：
我们在十多年前创办了这家公司。但天下已经变了，我们学会了如何开拓产品以及如何为那些为自己事情的人供应做事。自主创业的专业人士和他们的团队是劳动力大军中一个弘大且不断增长的部分……为了让 FreshBooks 能够跟上时期的步伐，并能够在五年内很好地做事于这个群体，我们知道我们须要采纳行动。
McDerment 借鉴了如何从头来过的一些传统思维：
对付软件公司来说，没有什么东西能够比重写软件具备更大的风险了。你乃至很可能无法完成这个项目。这比你想象的要花更长的韶光，花更多的钱。你可以这么做，但用户可能不会那么喜好。而且，建立一个新平台并不一定会得到一个更好的产品。软件开拓的第一原则是不要重构软件的平台。
因此，他们做了几次考试测验，试图在不从头开始的情形下整顿残局，但他们创造“在行驶的车子上换轮胎”是不可能的。
接下来发生的事情可能会惊到你
McDerment 末了想到的主张是秘密推出一个 FreshBooks“竞争对手”。
他在特拉华州成立了一家叫作 BillSpring 的新公司。新公司有自己的网址、品牌和 logo。为了避免这两家公司被联系在一起，他让一位外部状师起草了新的做事条款。
开拓团队将 Jeff Gothelf 和 Josh Seiden 共同撰写的“Lean UX: Designing Great Products with Agile Teams”作为开拓指南，并采取了敏捷实践，如 Scrum 团队和每周迭代，并与真正的客户举行评审会议。
McDerment 见告他们，要把自己想象成初创公司，并把他想象成公司的风险投资者。
“你们有四个半月的韶光。如果到时候你们可以进入市场，我们会给你们更多的钱。否则，你们就出局”。
在截止日期前几天，团队终于交付了一个 MVP。他们购买谷歌 AdWords 向新网站导流量。第一年，他们供应免费账户，不久之后就有了真正的用户，他们也开始通过快速迭代来完善产品。
一年之后，他们开始向 BillSpring 用户收取用度。然后一件意想不到的事情发生了：
有人打电话给我们，说要取消 FreshBooks，并说要转向 BillSpring。对我们来说，这是美好的一天。
不久之后，他们揭开了神秘的面纱：他们让 BillSpring 用户知道，BillSpring 实在是 FreshBooks 的，并让 FreshBooks 用户知道，他们很快就会推出新版本。
逐渐地，“FreshBooks Class”用户被约请试用新产品——他们也可以不接管，如果乐意，他们总是可以回到原来的版本。
学到的教训
FreshBooks 的秘密重写并不是没有代价的：McDerment 估计他们在这个项目上花了 700 万美元。经由十多年的自主增长，他们筹集了 3000 万美元的风险投资，以是他们有充足的资金。但并不是每家公司都有那么多钱可以花。
《福布斯》估计，FreshBooks 在 2013 年的收入为 2000 万美元。2017 年，在升级完成之后，他们赚到了 5000 万美元。他们并没有透露个中有多少增长是来悛改产品，但重写产品彷佛并没有减缓公司的增长速率。
McDerment 说，他们现在能够更快更随意马虎地往产品中添加新特性。更主要的是，现在的产品可以实现他们对未来的新想法。
然而，除了他们的既定目标，他们创造这种经历也改变了公司文化。他们假装初创公司的那段光阴让他们的行为更像一家创业公司。他们的“精益”实践扩展到了全体工程团队。用户密切参与了新功能的开拓。
FreshBooks 不遗余力将自己与重写的潜在负面影响隔离开来：在一个临时品牌之下进行创新，开拓职员可以完备重新思考问题，并承担更大的风险。最坏的结果便是他们会走到另一个去世胡同，但至少不会在这个过程中对现有的品牌造成任何危害。
我的一些想法传统不雅观点认为该当只管即便避免重写软件，而是进行增量式的改进——除非由于某种缘故原由无法这么做。
到目前为止，我还是赞许这一不雅观点。
不过，这个不雅观点假定了我们的终极目标是得到原始产品加上新功能的组合。
但如果你想要删除一些功能该怎么办？或者，如果你想用一种完备不同的办法办理某个问题呢？如果你通过体验产品得到了一个全新的想法呢？
我从这些故事得出的不雅观点是：如果你已经认识到，在当前产品和空想产品之间肯定存在差距，那么精确的方法不是用一个新产品更换旧产品，而是往旧产品里添加新的东西——不丢弃旧有的东西。
以是，如果你在考虑是否该当重写软件，你该当问问自己：我是否该当给自己制造一个竞争对手？如果我的产品是 FogBugz，那么 Trello 该当是什么样的？如果是 Visual Studio，那么 VS Code 该当是什么样的？
如果你重读 Spolsky 和 DHH 的文章，你会创造他们在一件事情上是保持同等的：已经创造出来的东西是有代价的。
好是，你不必为了创新而丢弃这些代价。
英文原文：
https://medium.com/@herbcaudill/lessons-from-6-software-rewrite-stories-635e4c8f7c22
