原文：Rewrite, refactor, or reinvent?
作者：Herb Caudill
从头审视这个老生常谈的问题：你是否应该从头开端重写你的运用程序，亦或是说这是 “任何软件公司都或许犯的最糟糕的战略过错”？事实证明，在处理一个老练的代码库时，有许多不同的挑选。
大约二十年前，Joel Spolsky 在他那篇具有里程碑意义的文章《Things You Should Never Do》中痛斥了网景公司重写代码库的行为。
依据以下两点，他得出的定论是：一个正常运转的运用程序永久都不应该从头开端重写。
- 运用程序代码库中的杂乱代码往往蕴含着来自边角事例和怪异bug的来之不易的阅历。
- 重写是一项冗长的作业，它会使你无法持续更新迭代现有产品，而在此期间，你面对的竞赛会越来越剧烈。
对许多人来说，Joel 的定论成了一种信条；它对我其时的思维产生了很大的影响。
在接下来的几年里，我陆续读到一些与之相反的观念，以为在某些特定状况下，从头开端重写是十分有意义的。比方说：
- 有时，留传的代码库的确被搞得无法修复，即便是一个简略的变更也需求对代码的其他部分进行一连串的修正。
- 本来的技能选型或许会妨碍你进行必要的改善。
- 或许，本来的技能或许现已过时了，导致很难（或很贵）招聘到高质量的开发者。
当然，究竟是逐步重构留传代码更好仍是把它全部扔掉从头开端更好，许多时分都得结合实践状况，详细问题详细分析。
但这并不是唯一的挑选。从下面的六个故事中，看看咱们得到到什么启示。
Netscape
Netscape ... 4.0 5.0 ☠ 6.0 7.0 ☠
⤷ Mozilla 1.0 ☠
Firefox 1.0 ----------
Key: = rewrite ☠ = dead end
Netscape 灾难性的 5.0/6.0 重写是“永不重写”的经典事例。
界说了前期商业互联网的网景导航者（Netscape Navigator）于 1994 年初次发布。不到两年时刻，该公司进行了 30 亿美元的初次揭露募股（IPO），开启了互联网泡沫年代。
1996年，Netscape 第一个真实的竞赛对手，微软的 Internet Explorer 问世。
到了 1998 年初，Netscape 依然是商场份额最高的阅读器，但仅仅是牵强坚持抢先。Netscape 的零售价格为 49 美元，而微软则免费供给 IE，并将其作为默认阅读器随 Windows 一同发布。
在Netscape 4.0 版别发布之后，该公司宣告将免费供给一个由该公司创立和赞助的开源社区 Mozilla 进行开发的 5.0 版别。
这在其时基本上是前所未有的，Netscape 由于这一斗胆的举动赢得了许多的好感。可是，事实却是，这个社区并没有真实构成。该阅读器最早的开发者之一 Jamie Zawinski 解说说：
事实上，Mozilla 项目的奉献者包含约一百名全职的 Netscape 开发人员和约三十名兼职的外部开发者，这个项目依然完全归于 Netscape。
该团队总结出来外部开发者没有爱好为他们的开源项目做出奉献的一个原因便是现有的代码库紊乱不胜。
代码过于杂乱和紊乱，导致任何改动都十分困难，这也是为什么社区开发者不愿意参加…这也是为什么咱们决议转向新的布局引擎。一个愈加简洁的全新规划的代码库，从理论上讲，更简单被人们了解并参加奉献。
从头开端
于是在一年之后，团队决议抛弃 5.0 版其他作业，而且从头开端开发 6.0 版别。
又过了两年，Netscape 6.0 才总算发布；即便过了这么长的时刻，很明显它都仍是在没有完全准备就绪的状况下发布的。依据《纽约时报》的评论员 David Pogue 的说法，光是启动阅读器就需求整整一分钟！而且它会占用许多内存。此外，前一代阅读器上的一些简略易用的功用也不支撑了：
打印预览功用没了，也无法经过拖动网站地址栏图标直接进入书签菜单。你再也不能经过右键点击地址栏仿制或张贴网址了。每次开端阅读时都有必要调整阅读器窗口巨细，由于导航器不记得上次运转程序时窗口的巨细。最令人忧虑的缝隙是，你无法经过一次点击来高亮整个地址栏。
最重要的是，在 Netscape 停滞不前的三年里，Internet Explorer 现已占据了一切剩余的商场份额：
当重写开端时，Netscape 在微软的 Internet Explorer 面前迅速失掉阵地。三年后，新版别总算发布，但它存在许多问题且运转速度缓慢；一同，Netscape 的商场份额现已简直消失。（图表摘自维基百科）
1999 年，重写正在进行中时，AOL 以 100 亿美元的交易价格收买了 Netscape。
在 Netscape 6.0发布两年后，AOL 内部的 Netscape 团队解散了。
Mozilla，这个 Netscape 创立的开源社区，在 2002 年发布了 Firefox 阅读器 —— 这是 Firefox 阅读器的又一次重写。Firefox 的确设法从微软那里夺回了一些商场份额。
可是，作为一家公司的 Netscape 现已消亡了。(讽刺的是，微软在 2012 年与 AOL 达成了一项协议后，终究获得了 Netscape 的知识产权的剩余部分。)
在赢得那场战争后，微软撤回了对阅读器技能的投资。2001 年发布的 IE6 在接下来的五年里没有任何晋级，这在一些人看来是一种成心的战略，以防止网页成为运用程序的渠道。
感悟
有人以为，久远来看，这次重写并不是一场灾难，由于这个项目终究导致了 Gecko 引擎和 Firefox 阅读器的出现。
但在等待新的阅读器崭露头角的一同，咱们都不得不忍耐 IE6 无休止的、令人窒息的垄断，这导致网络技能多年停滞不前；而且终究完毕 IE6 年代的并非 Firefox，而是谷歌的 Chrome。
无论怎么，眼下的问题不是重写是否对互联网有益，而是从做出决议方案的公司的角度来看，这是否是一个正确的决议。
尽管 Netscape 的衰败并非完全是由重写导致的，法院也认同微软存在成心乱用垄断权利的行为。
可是重写的确是一个关键因素，终究成果是一家价值数十亿美元的公司倒闭，数千名职工失业。因而，我同意 Joel 的观念，这次重写的后果是灾难性的。
Basecamp
Basecamp Classic --------------------------------------------- ->
Basecamp 2 ------------------------------------- ->
Basecamp 3 ------------------------- ->
21 世纪初，芝加哥的一家名为 37signals 的网页规划公司，经过创始人 Jason Fried 和 DHH 独树一帜的博客的影响力积累了一大批追随者。
我最开端关注他们的时分，仍是一个刚开端做网页规划的新人，那时他们对像谷歌和 PayPal 这样的网站进行了一系列未经请求的从头规划，这些网站被称为 37better。
近 20 年后，37signals 对联邦快递（FedEx）的运送表单的从头规划（上图）依然比实践运转的产品（下图）要好。
2004 年，他们将内部运用的项目办理东西作为一款 SaaS 产品推出商场，他们将其命名为 Basecamp。
其时，订阅软件仍是一种新鲜事物。项目办理东西以盒装产品的形式出售，价格高昂，顺便繁琐的操作手册，首要用于建模关键途径和生成杂乱的甘特图。
Basecamp 售价为 50 美元每月，它具有超级简洁的界面和专心于交流的特色，给人一种焕然一新的感觉。
几年后，Basecamp 具有数十万名安稳的用户，每个月都有丰厚的收入进账，但 Jason 和 David 却开端变得感到焦躁不安。
几年前我在软件商务大会上听 David 共享了这个故事。他说，他不只被 Joel Spolsky 说服了重写软件会销毁整个公司，还遭到了灵敏开发运动的影响，这使他产生了一种自以为是的主意：
我完全沉浸在那种超前软件理念中……代码是无限可塑的。留传代码有无限的价值。任何软件、任何代码都可以轻松地进行重写……假如不能，那便是你的职责。你需求反思自己的缺少，并尽力提升自己的编程技能。
可是，在他所谓的“七年的黄金时期”之后，他们堕入了困境——与技能债毫无关系。
金手铐
他们注意到自己不再像之前那样充溢热情。他们不只没有动力去开发自己的旗舰产品，乃至他们自己都不怎样用这个产品。
他们有许多关于怎么从根本上改善产品的主意，可是跟着不计其数的人在 Basecamp 创立作业流，他们所做的每一个改动都会对许多许多人造成损坏。改动的妨碍不是紊乱不胜的代码库，而是他们的用户。
他们专心于坚持现有客户群的满足度，这使得产品在时刻上处于被冻结的状况，无法再招引新用户。这对企业来说不是一个直接的问题，但它构成了一个长时刻的威胁。DHH 用了一个堵住漏水的水桶的比喻：
你或许堵住了一切的缝隙、修复了一切的 bug、晋级了一切现有客户诉苦的功用，你以为这样就滴水不漏了——但水总是会漏的。跟着客户作业的不断推进，他们不再运用你的软件，即便他们[酷爱它]。但你依然可以掩耳盗铃：“你看，水桶一大半是满的。那仅仅一个微缺少道的缝隙，从那里渗点水出来是很自然的。”可是，假如这个状况持续的时刻满足长，水桶里终究会一滴水都不剩。
问题的部分原因在于：你听到的永久是现有用户的声响，但你听不到未来客户的声响。
你觉得咱们什么时分会收到那些几年后访问 Basecamp 主页，却由于咱们的主意不够好而挑选不购买的人群的反馈？永久都不会。咱们听到的永久都是现有客户的声响，这部分用户最期望的是咱们的产品坚持现有的安稳性和可靠性，咱们只要持续修补一些小缝隙就好。
他们开端将自己的盈余产品视为一副金手铐：
首要的作业是保证现有的用户依然感到满足。这样每个月都会有连绵不断的现金流。但与此一同，你有必要向他们保证：“Okay，我再也不会改动我的软件了。”
剧透：他们花了大约一年的时刻从头开端重写了 Basecamp，成果十分理想，新用户注册量在 Basecamp 2 发布后立马翻了一番。
我以为，他们的这次重写能取得成功，得归功于两件作业：
首要，他们没有试图从头构建他们现有的产品ーー由于他们关于怎么处理他们开端打算处理的问题有了新的主意。
咱们真的傲慢到深信咱们在 2003 年所提出的理念，到了 2011 年依然是最好的吗？曾经，许多人批判我过于自负，可是在 2008 年左右我都不这么以为了。
因而他们把 Basecamp 2 作为一个全新的产品推出，而且不向后兼容 Basecamp Classic。加入了许多新功用，删掉了一些老功用，还有许多东西和之前完全不相同了。
这个决议方案给予了他们必定程度的自在。这种自在度激发了团队成员的内在动力。他们可以放开手脚去做更多的作业。
不必支撑原始产品的每一个运用事例也为他们节省了许多时刻。例如，本来的 Basecamp 答运用户在自己的 FTP 服务器上保管文档。除掉这个功用以及其他相似的功用（这些功用在曩昔或许具有商业意义，但现在已不再适用），使得他们可以在合理的时刻内推出新产品。
“日落”是有害的
可是那些不计其数的诉苦他们的利益遭到危害的现有用户怎样办呢？
这就引出了他们做的第二件作业，那便是他们没有抛弃现有的产品。
David 对软件“日落”这个概念进行了一番演绎：
有人在某个旮旯编造了一个美丽的委婉说法——“日落”。让咱们以“日落”来形容终结软件的过程。用户们沐浴在海滩上，注视着他们的数据逐步消逝，那将是一幅多么美丽的画面啊！
可是，唯有那些称之为“日落”的人才会信任其间的美妙。那些实在阅历过软件下线的用户并不会回过头来宣告“美不胜收”的慨叹。相反，他们会愤怒地责问：“艹！我在这个软件中付出了这么多年的汗水！现在你们就这么把老子当成“日落”了？”
他指出，当你逼迫用户迁移时，那便是犯下了“有史以来最糟糕的战略过错”。由于你会让整个重复购买的用户群体开端考虑是否要持续运用你的软件，或许完全转向其他挑选。
“Basecamp 真的仍是我想要的吗？假如我有必要迁移一切的数据，或许我可以顺便测验一下其他的挑选。假如我有必要将一切东西打包装箱，然后装上卡车，这辆卡车就没有必要非得回到出发的原点。搬家真实麻烦是将我的一切东西打包起来。它是回到 Basecamp 仍是搬去其他什么地方，就不那么重要了。”
David 将 Basecamp Classic 比作徕卡 M3 相机：尽管它自 1967 年以来就不再生产，但徕卡依然致力于它的售后和维修服务，只要他们还在营业。（图片来历：Dnalor 01）
相反，Basecamp 承诺“尊重他们的前史数据”：他们尽或许简化用户的晋级操作，但并不要求用户抛弃 Basecamp Classic。不只如此，他们还承诺将无限期地持续保管、支撑和保护 Basecamp Classic。
出人意料的是，四年后，Basecamp 团队再次进行了相似的操作：Basecamp 3 在 2015 年发布，这是一个全新的重写版别，移除了一些功用，新增了一些功用，许多元素都进行了改动。和之前相同，旧版其他用户可以轻松地晋级，但他们也可以挑选持续运用 Basecamp Classic 或 Basecamp 2 “直到互联网国际的止境”。
Basecamp 3 不会使任何版别消失。无论是 Basecamp 2，仍是 Basecamp Classic。任何一个版别都可以很好地为您服务。请持续运用它们直至互联网的止境！咱们会保证它们快速、安全且始终可用。
可是，可是，可是，那不是很贵重吗？那不是很困难吗？安全问题呢？留传代码库呢？是的，那又怎样？对咱们来说，照顾好每一个客户——即便他们对按照咱们的时刻表进行晋级不感爱好——是咱们的职责所在。
感悟
个人而言，我觉得这个模型十分令人振奋。
每次重写都让 Basecamp 有时机从头审视规划决议方案，并构建出他们期望在上一次构建时就能完结的产品。
对用户来说，这是最好的两全之选：那些不喜欢改变的人不会失掉他们熟悉的环境，而那些遇到产品约束的人则能运用一个新的、经过深思熟虑的运用程序。
无限期保护多个版其他产品并不是没有价值的，但正如 David 所说：
这并不是没有价值的。你为什么会有这种期望呢？这件作业是十分有价值的，所以当然不会是 0 成本的。但它值得咱们这么去做。
Visual Studio 和 VS Code
VS 97 -> 6.0 -> .NET -> ... -> 2015 -> 2017 -> 2019 ------- ->
VS Code ------------- ->
Key: = street cred
微软开发 VS Code 的目的是为了招引那些在其他渠道上作业的开发者。
想必你还记得，在很长一段时刻里，运用微软的东西意味着要全盘承受其生态体系。假如你运用 Visual Studio，就得运用 .NET，反之亦然。这将软件界分成了两个巨大的、相互排挤的阵营，这对一切人来说都是晦气的。
接触新年代开发者
这种分裂乃至在 Steve Ballmer 的年代就开端了——还记得当 ASP.NET 团队决议复用 jQuery 时，引起了多大的轰动吗！
招引那些在微软关闭生态之外的开发者，是微软 CEO Satya Nadella 明确提出的任务之一。
但正如《The Changelog Podcast》中的嘉宾、Visual Studio 副总裁 Julia Liuson 所说：
咱们之前没有任何一款面向这一类开发者（现代化、面向 Web、以 Node 和 JavaScript 为主的开发者）的产品，咱们无法与你们交流。你们是咱们无法招引的开发者群体。
因而，开发 VS Code 的动机便是要打破这个妨碍，告知你们：“实践上，咱们的确有一款合适你们运用的东西。”
Visual Studio 是一款从各个方面来说都相对巨大的产品：装置或许需求半小时乃至更长时刻。它有必要支撑企业客户所依靠的各种杂乱用例。因而，运用 Visual Studio 自身作为起点，并经过增加功用来招引其他渠道的开发者是没有意义的。而且可以幻想，开发适用于 Mac 或 Linux 的 Visual Studio 版其他主意是行不通的。
因而，微软挑选在不保证向后兼容的条件下从零开端。
实践上，并非完全从零开端：微软现已有一些重要的组件可供运用，比方依据阅读器的 Monaco 编辑器。而且由于 VS Code 是一个 Node.js 运用（运用 TypeScript 编写并在 Electron 中运转），他们可以运用丰厚的JavaScript 生态。
VS Code 是一款开源的、轻量级的、快速可扩展的产品；而且令人惊奇的是，作为一款微软产品，它现已成为了新年代开发者的首选编码环境。
依据 2018 年《JavaScript 现状调查陈述》的数据显现，VS Code 已成为 JavaScript 开发者的首选文本编辑器。
这两款产品仍在活跃开发中，并没有迹象显现微软打算中止支撑 Visual Studio。
感悟
与 Netscape 的阅历构成鲜明对比，微软成功地环绕 VS Code 建立了一个活泼的开源社区。这个社区使得开发团队的尽力获得了事半功倍的作用。
巧合的是，在 GitHub 的一切开源项目中，Visual Studio Code 的 star 数排名第 13 位，恰好排在 Linux 下面！
当然了，并不是每个人都有一个可以支撑将核心产品完全开源的商业模式。
但假如开源是你的开发战略的一部分，对比研究这两个事例，了解微软是怎么做出异乎寻常的举措从而让整个社区蓬勃发展的，或许会对你有所裨益。
另一个促进因素是，微软为 VS Code 供给了安稳可靠的可扩展性模型，其成果是社区编写了近 10,000 个扩展插件。
尽管关于如今东西集的杂乱性存在诸多忧虑，但事实上，JavaScript 生态体系在曩昔几年中现已发展成为一个可复用、模块化的开源代码理想国。从这个角度来看，这是一个具有前史意义的前所未有的年代。
Gmail 和 Inbox
Gmail ----------------------------------------------------- ->
Inbox for Gmail ------ ↗ -- ↗ -- ↗
Key: = sunset
Inbox for Gmail 开端是作为 Gmail 的一种简化 UX 而推出的，旨在专心于真实重要的事项。它与原始的 Gmail 在功用上并不完全共同，并引入了如邮件绑缚、置顶邮件、延迟音讯等新功用。
包含我在内一些人，对 Inbox 表示热情的承受。我一直以为 Inbox 是 Gmail 的先行预览版，愿意容忍其间缺少一些 Gmail 的细节，并期望它们终究会出现在 Inbox 中。
两套界面，一个服务
无论是 Inbox 仍是 Gmail，它们都运用相同的后台服务。实质上，它们仅仅同一服务的不同用户界面，你可以随意切换运用。这种做法有其优点也有缺点：假如 Inbox 缺少某个功用（比方自动回复假期邮件），你可以切回到 Gmail，在那里完结你需求的操作。但在来回切换时，不免会有一些奇怪的状况发生。
可是，过了一段时刻，Inbox 的改善停滞不前，很明显 Google 已不再投入任何资源。果不其然，在 Inbox 推出四年后，Google 宣告中止支撑 Inbox。
起先我感到十分恼火，但在花了一些时刻运用最新版其他 Gmail 后，我发现许多我在 Inbox 中喜欢的功用都现已被移植到了原始产品中：智能回复、悬停操作、内联附件和图片。Gmail 的多个收件箱可以很好地替代 Inbox 的绑缚功用。
但并不是一切功用都被移植过来，比方延迟发送功用，它是许多人处理电子邮件的重要办法，而 Inbox 的消失让他们失掉了这个功用。
感悟
Inbox 为 Gmail 团队供给了一种测验新功用且不会搅扰那些挑选不切换的绝大多数用户的作业流程的办法。
可是，让两个版别运用相同的后端，严格地约束了 Gmail 的立异能力。
谷歌再次因关停一个受欢迎的服务而遭到诸多批判。当然了，谷歌一直在不断地关停产品，咱们能有什么办法呢。
在这个事例中，谷歌开端对 Inbox 的宣传让咱们信任咱们提早看到了 Gmail 的未来。诚如 DHH 所说，这并不是一次美丽的“日落”；对许多人来说，不得不回到旧产品并失掉 Inbox 的立异作业流程是操蛋的。
我以为假如在关停之前，Gmail 可以完全到达与 Inbox 功用的平衡，那么或许会削减一些不满的心情。
FogBugz 和 Trello
FogBugz ------------------------------------
Trello --------------------------- ->
Key: = sad decline = money money money
FogBugz 是一个特别有趣的事例，由于它正是由 Joel Spolsky 发明的产品。它让咱们看到了从实践产品角度来看，永不重写原则是怎么发挥作用的。
在 Jira 和 GitHub Issues 出现之前，有一款名为 FogBugz 的依据 web 的 bug 盯梢产品。它发布于 2000 年，是 Joel 与 Michael Pryor 一同创立的 Fog Creek 软件公司的首个产品，而且在超越十数年的时刻内都是他们的旗舰产品。开端，他们仅仅将其作为装箱软件出售，供用户装置在自己的服务器上，后来又推出了保管式订阅版别。
FogBugz 十分流行，特别是在像我这样的开发者（关注 Joel 的博客并将他的主张奉为圭臬）。我司多年来一直运用它，它是其时十分优秀的一款产品。
FogBugz 开端是用 ASP 编写的，运转在 Windows 服务器上。当 ASP.NET 发布时，Joel 解说了为什么他不急于晋级。
为了可以在 Linux 服务器上装置 FogBugz，一名实习生编写了一款名为 Thistle 的编译器，用于将 ASP 转换为 PHP。到了 2006 年，Thistle 发展成为一门内部编程言语—— Wasabi，它可以编译成 ASP、PHP 和客户端 JavaScript。
Wasabi 奇谭
现如今，开发一种内部专有的编程言语和编译器可以说是一个反常的挑选。所以，请答应我稍作违背主题的简要介绍。
在一篇博文的结束，Joel 随意提到了 Wasabi，描绘了它的存在。但明显有些人以为他便是随口一说，因而他特别进行了澄清，表示自己是仔细的。这使同为博主的 Jeff Atwood 极为震惊：
编写自己的编程言语肯定是不可思议的举动。这是一个有害的决议方案，与 Joel 之前在软件开发方面供给的超卓的、理性的主张完全相悖，以至于许多人都以为他是在恶作剧。
Joel 坚持以为这是有商业意义的：当然，假如你从零开端，你不会去开发自己的编程言语。但假如你逐个考虑一路过来的每个决议方案，考虑其时的技能环境和他们其时的代码库，你就会理解为什么会走到那一步。
在一篇名为《Technical Debt and Tacking Into the Wind》的文章中，前 Fog Creek 工程师 Ted Unangst 将开发 Wasabi 的过程比作一场没有地图的旅行：
设想一下，你身处佐治亚州的萨凡纳，怀揣着前往英国伦敦的梦想。但你没有地图，只要一个模糊的方向感…在你面前的是一片浩瀚的大海，你无法直线前行，除非你自己造一艘船。可是，在你的东北方向，延伸着一片迷人的沙滩，指引着你心中神往之处。你毫不犹疑地踏上旅程。岁月不居，时节如流。你知道自己并没有径自走向目的地，但你每迈出一步都在向它接近。
终究，你在波士顿或许新斯科舍的某处停下来考虑你的挑选。或许这并非通往伦敦的路途。从高高在上的看客中传来阵阵嘲笑声：“哈哈哈，看看这群白痴，根本分不清英格兰和新英格兰的差异，给这群傻子弄一张地图吧。”但这正是问题所在，你没有地图。地图往往是由那些不知道自己要去往何处的人绘制的。
无论怎么，正如前 Fog Creek 开发人员 Jacob Krall 作出的解说，这个决议方案是以当下的开发速度为价值，交换未来的可保护性 —— 这正是技能债的界说 —— 到了 2010 年，这笔技能债的账单开端到期了。
咱们没有将 Wasabi 开源，因而任何投入都有必要由咱们自己承当，而这会危害咱们首要的收入来历产品。咱们需求雇佣全职的开发人员，关于咱们这样规模的公司来说这并不廉价。有时，它会在对人类来说完全合理的代码上出现问题。它的编译速度很慢，而且无法轻松地在 Visual Studio 中进行编辑或连接到 FogBugz 调试器上。关于一切新职工来说，不论他们之前的阅历怎么，他们都需求花费许多时刻来学习 Wasabi。此外，咱们并不是生活在一个关闭的环境中。其它编程言语在不断改善。开发人员开端感到咱们小小的 Wasabi 国际约束了他们的杰出主意。
转折点
十年后，FogBugz 现已成为一个老练安稳的产品。Joel 与 Jeff Atwood 一同创立了 Stack Overflow 作为他们的副业项目（或许此时 Joel 的脑筋总算康复正常了）。
可是，FogBugz 并未引起火热反响，而且显现出了它的老化迹象。尽管 bug 盯梢器商场依然存在碎片化的状况，可是 Atlassian 公司在 FogBugz 问世之后几年才推出的 Jira 成为了（尤其是关于较大的企业用户而言）首选产品。
我对 Fog Creek 前史上的这个转折点十分着迷。就像 Basecamp 相同，他们具有一款盈余且老练的产品。这款产品现已不再具有招引力，或许关于开发人员来说也不太令人兴奋。不论好坏，他们都代表了多年来技能革新和处理特定问题范畴的不断发展的思维。
当然，针对这种状况，可以采纳像 Basecamp 那样的战略：运用 Fog Creek 在缺点盯梢方面的阅历，从零开端从头构建 FogBugz，从头规划产品。
但我猜这个战略并不会被选用——由于那是“永久不要做的作业（《Things You Should Never Do》）”，“最糟糕的战略过错”……
我最近看到了一篇撰写于 2009 年的文章，其时 Joel 在为《Inc.杂志》撰写月度专栏——《Does Slow Growth Equal Slow Death?》。与他一般自信而夸大的口吻截然不同：这篇文章愈加内省、犹疑和充溢置疑。他对 Atlassian 的快速增加感到忧虑，考虑在缺点盯梢商场中是否只要一个产品能存活下来。
我不得不考虑。市面上，有一家竞赛对手好像比咱们增加得更快。该公司正在与大型企业客户签订严重交易。明明咱们的产品更好，咱们也是一家办理杰出的公司，但这好像并不重要。为什么呢？
因而，他决议采纳两个行动。首要，给 FogBugz 增加许多的功用：
咱们开发团队在 2010 年的任务便是：消除顾客由于一些他们自以为肯定无法脱离的细节功用而购买竞赛对手废物产品的任何或许。坦率地说，我以为这并不难。
其次，建立一支企业出售团队。Joel 也供认这是他不拿手且讨厌的作业。
我不知道这两个方案的详细执行状况。Joel 在他的博客上终究一次提到 FogBugz 仅仅几个月后发布了一则次要版其他简略公告。
新期望
作业是这样的：
在 Fog Creek 建立十周年之际，我开端考虑，假如咱们想让职工在接下来的十年里坚持热情和动力，咱们得需求一些新项目。
因而，他们将团队分成了两个小组，每个小组负责提出和原型化一个新的产品。
取胜的小组遭到 Kanban 的启示——这是一种在软件开发中常用的物理东西，一般包含将便利贴按列贴在白板上。
Joel 将其描绘为一种可以在比 FogBugz 更高层次上办理作业的东西：
老实说，在那么多花哨的“项目办理”软件中，我从未找到一种可以有效追踪谁应该做什么作业的办法。……作为两家公司的创始人，每天走在走廊上看到那么多人坐在电脑前领着薪水，却不知道他们是否在做正确的作业，或许或许他们以为重要的作业实践上并不重要，这让我开端感到分神了。
经过构建 Trello，Fog Creek 的开发人员有时机测验运用最新的技能：
咱们运用前沿技能。可是，这一般也意味着咱们会遇到一些挑战。咱们的开发人员在运用 MongoDB、WebSockets、CoffeeScript 和 Node.js 时或许会面对一些困难。但至少他们享受其间的过程。在当今竞赛剧烈的就业商场中，优秀的程序员对他们即将从事的作业有很大的影响力。假如能给他们一个令人兴奋的产品……他们会乐在其间，对自己的作业也会充溢酷爱。
Trello 还在一开端就支撑第三方插件，这样可以使内部开发团队的尽力成果倍增：
API 和插件架构是咱们最重视的部分。假如有或许，咱们会经过供给基本的 API 让那些高价值用户为咱们开发功用。在 Trello 团队中，任何可以由插件完结的功用都有必要由插件供给。
毫无疑问，程序员们马上就看到了 Trello 的实用性；但东西自身并没有特定针对软件开发的功用。Joel 称其为适用于“任何需求与一群人一同保护列表的事物”。很快，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 将产品卖给了一家名为 DevFactory 的小公司，这家公司很快就把产品名改回了 FogBugz。
在 CEO Anil Dash 的领导下，Fog Creek 成为了一家单一产品公司，并正式更名为 Glitch。
感悟
对这一切，我感触颇多。
打造一个舒适的作业环境是咱们的首要目标。咱们供给私家办公室、头等舱机票、每周40小时的作业时刻，还给职工供给免费午餐、Aeron 座椅和顶级的电脑。咱们向全国际共享了咱们的奇妙公式：杰出的作业环境 → 优秀的程序员 → 超卓的软件 → 利润！
了解整个故事的关键在于，Fog Creek 一直致力于赋予程序员更多权利，而不只仅是关于缺点盯梢：
以这个“公式”为根底，或许咱们可以构建一个连接而鼓舞人心的故事：Fog Creek 以开发者的幸福感为基中心打造了一个企业。这既体现在公司的产品上，也体现在其内部的“运营体系”中。其第一代产品，一个缺点盯梢东西，为推出一个以更广泛适用办法处理相似问题的新产品供给了根底。
我以为这真实有意思的地方在于，依据 Joel 叙述的 Trello 的起源故事，与其说 Joel 在寻觅新的商机，不如说 Joel 在寻觅一种让 Fog Creek 的开发者坚持快乐和投入的办法。发明出一个价值数十亿美元的产品，仅仅一个愉快而意外的成果。
关于 FogBugz 的终究命运，我也无法不感到些许悲伤。我想，在 Fog Creek 终究的日子里，产品或许并不会给开发者带来太多的快乐。
明显，一切参加其间的人都有更重要的作业要忙：Stack Overflow、Trello 和 Glitch，每个都比 FogBugz 愈加有价值；而每个人在有限的时刻内只能投入有限的精力。因而，我不能对任何个别人对 FogBugz 失掉爱好感到仇恨，究竟它具有着二十年前史的代码库和竞赛剧烈的细分商场。至少，它的忠诚用户找到了一个杰出的归宿，而不是被当成“日落”对待！
可是，我内心深处的情感仍是期望可以以更好的办法“铭记”一切那些多年来为它做出奉献和运用它的人们的“遗产”。
FreshBooks 和 BillSpring
FreshBooks ------------------------------------------------ ->
️BillSpring ------- ↗
Key:️♀️ = undercover operation
这篇文章现已比我预期的要长得多，但我不能漏掉这个有着精彩转折的故事。请必须持续读下去。
除非你之前听过这个故事
21 世纪初，Mike McDerment 开了一家小型规划机构。他以为传统的管帐软件对他的需求来说过于杂乱，决议运用 Word 和 Excel 来制作发票。
这套体系一开端十分好用，直到逐步不再满足需求：Mike 是一名规划师，而非程序员，但他和其他两位联合创始人设法拼凑出一个满足好用的东西，以每月 10 美元的价格招引了一些用户。他们花了近四年的时刻才赚到满足的积储，让 Mike 可以搬离父母家的地下室。
有一天，我意外地覆盖了一份重要的客户发票，这让我到达了溃散的边际。我意识到有必要有更好的处理方案，于是我花了两周时刻编写了现在成为 FreshBooks 根底的代码。
在产品建立 10 周年之际（听起来有点熟悉了吧？），FreshBooks 现已安稳盈余，具有超越 1000 万用户和 300 名职工。
只要一个问题：当他们终究雇佣了“真实的”程序员时，他们现已有了一百万行的“创始人代码”。一位外部分析师检查了他们的代码库，并得出这样的定论：
“好音讯是，你们处理了最困难的问题。你们找到了怎么经营一家企业的办法，而且具有一款深受人们喜欢的产品。坏音讯是，你们的代码便是一堆『屎山』。”
可是，更重要的是，他们有一些新的主意，而现有产品无法满足这些主意的完结：
公司建立现已超越十年了；跟着国际潮流的改变和咱们关于为自在职业者供给服务的深化了解，咱们积累了许多打造产品和满足自在职业者需求的阅历。自在职业者及其团队是劳动力商场中巨大且不断增加的一部分… 为了可以与时俱进并在未来五年内更好地为他们供给服务，咱们有必要要采纳行动。
McDerment 现已对从零开端的知识有了深化的了解：
关于软件公司来说，没有比重写更大的危险了。很或许你乃至无法完结项目。它会比你幻想的时刻更长，花费更大。当你这样做时，顾客或许会对其不太满足。而且，你并不能保证经过构建一个新渠道就能得到一个更好的产品。在软件范畴，有一个首要的规矩，便是不要从头构建你的软件。
因而，他们测验在不重写的状况下进行优化，但终究发现“边开车边换胎”是不或许的。
令人咋舌的操作
McDerment 终究决议秘密地打造一款 FreshBooks 的竞品。
他在特拉华州注册了一家名为 BillSpring 的新公司。这家新公司有自己的网址、品牌和 Logo。为了保证这两家公司之间没有关联，他让一位外部律师起草了新的服务条款。
开发团队选用了 Jeff Gothelf 和 Josh Seiden 所著的《精益UX：与灵敏团队规划超卓产品》作为他们的行动指南，并引入了灵敏实践。McDerment 告知他们要把自己视为草创公司，将他视为危险投资人。
“你们还有四个半月的时刻。假如到时分你们能进入商场，咱们将供给更多资金支撑。否则，咱们会退出项目。”
在第一年完毕时，他们开端向 BillSpring 的客户收费。而这个新产品的验证办法却出人意料：
在截止日期前几天，团队成功开宣告了最小可行产品（MVP）。他们购买了 Google AdWords 来增加新网站的流量。首年他们供给免费账户，很快就获得了实在用户，并开端快速迭代以完善产品。
“有人给咱们打电话取消了 FreshBooks 订阅，并告知咱们，他要转用这个新公司的产品。” McDerment 说：“那天是个好日子。”
不久之后，他们揭露了这个秘密：向 BillSpring 的客户宣告产品现在变为 FreshBooks，一同告知现有的 FreshBooks 客户将很快推出新版别。
逐步地，“FreshBooks Classic”的客户被约请测验新的晋级版别，但这并非是强制性的，假如他们愿意，他们随时可以迁回到更为熟悉的版别。
感悟
FreshBooks 的秘密重写并不廉价：McDerment 估量他们在这个项目上花费了700万美元。在阅历了十多年的自主生长后，他们刚刚筹措到了 3000 万美元的危险投资；所以他们有满足的现金。并非每个人都有这么多的资金可以投入。
据《福布斯》估量，2013 年 FreshBooks 的收入为 2,000 万美元。在完结晋级后的 2017 年，他们的收入到达了 5,000 万美元。他们没有透露这种增加中有多少来自新产品，可是重写好像并没有减缓公司的增加速度。
McDerment 陈述称他们现在可以更快、更简单地增加功用。更重要的是，他们具有了一个可以完结他们最好构思的产品来迎候未来的挑战。
除了他们所陈述的目标之外，他们发现这一阅历以一种活跃的办法改动了公司文明。他们在扮演草创企业的角色期间，变得更像一家草创企业。他们试验的“精益”实践办法传播到整个工程团队中。客户亲近参加到了新功用的开发过程中。
FreshBooks 采纳了十分极点的措施来防止重写或许带来的潜在危险：经过立异地运用一个暂时品牌，开发人员可以完全从头考虑事物，并承当更大的危险。这样，最坏的状况便是他们或许再次堕入僵局，但至少在这个过程中不会危害他们现有的品牌。
这种做法或许有些极点，或许没有必要像他们那样做得那么完全。但这也提醒咱们，重写的危险有多高。
写在终究
众所周知，关于重写软件的知识是，一般状况下应防止重写，而是进行渐进式重构——除非出于某种特别原因的确不可行。
就目前而言，我同意这一观念。
可是，这个主张的条件是终究目标是在原有产品的根底上增加一些新功用。
但假如你是想删去某些功用呢？又或许你想以完全不同的办法处理某个运用场景呢？假如你的产品运用阅历给你带来了对一种全新方案的主意呢？
我从这些故事中得出的定论是：一旦你认识到当时版其他产品与你所幻想的最佳版别之间存在必定的差距，那么正确的办法不是用新版别替换你的软件，而是在保存现行版其他一同，从头构建一个新项目。
因而，假如你在正在考虑是否应该进行重写，或许你可以审视一下你的产品，然后问问自己：我能否发明出自己的竞赛对手？假如我的产品是 FogBugz，那么我的 Trello 会是什么？假如它是 Visual Studio，我的 VS Code 会是什么样子？
假如你回头再重读 Spolsky 关于 Netscape 的帖子和 DHH 关于 Basecamp 的帖子的话，你会发现他们在一件作业上的观点是共同的：你现已发明的东西是有价值的。
好音讯是，你不必为了立异而抛弃这种价值。
