編碼一時爽，重寫火葬場？這些公司都重寫了軟體，結局卻不同

作者 | 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. Basecamp

2000 年代早期，芝加哥的一家名為 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 和 Inbox

Gmail 的 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 和 Trello

FogBugz 是一個特別有趣的案例，因為它是 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 和 BillSpring

2000 年代早期，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

除了軟體重寫之外，系統架構也需要不斷的換血。

阿里巴巴在收購東南亞電商 Lazada 之後，僅利用 6 個月時間就完成了對 Lazada 的整體重構，將網站的可用性能提升到了新高度。

7 月 12 日深圳 ArchSummit 全球架構師峰會，Lazada 前 CTO 陳思淼老師作為親歷者將分享，他對整個項目的技術選型的實踐和團隊搭建的思考內容。

此外，會議上還準備更多的技術分享大餐，歡迎現場體驗：

蘋果 Siri - Spark 性能提升的最佳實踐

陸金所 - 機房一鍵切換平台建設

位元組跳動 - 容器化場景下的性能優化實踐

百度 - 春晚極限壓力場景下的運維解決方案

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！