祭祀架構

你坐在會議中，思考著團隊過去幾年來編寫的程式碼。你決定現在能做的最好的事情就是拋棄所有程式碼，並在全新的架構上重建。這讓你對那段注定失敗的程式碼、你花在上面工作時間，以及你當時所做的決定有何感想？

對許多人來說，拋棄程式碼庫是失敗的象徵，也許可以理解，因為軟體開發本質上具有探索性，但仍然是失敗。

但通常你現在能寫出的最佳程式碼，就是你幾年後會捨棄的程式碼。

我們通常認為偉大的程式碼是長壽的軟體。我正在使用可以追溯到 1980 年代的編輯器撰寫這篇文章。許多關於軟體架構的思考是如何促進這種長壽性。然而，成功也可以建立在早已傳送至 /dev/null 的程式碼之上。

想想 eBay 的故事，這是網路上最成功的幾家大企業之一。它始於 1995 年週末建立的一組 perl 腳本。1997 年，它被全部拆除，並替換為一個使用當時 Windows 工具在 C++ 中編寫的系統。然後在 2002 年，應用程式再次使用 Java 重新編寫。這些早期版本是否因為被取代而成為錯誤？不太可能。到目前為止，eBay 是網路上最成功的企業之一，但它的成功大部分建立在 90 年代被捨棄的軟體上。與許多成功的網站一樣，eBay 經歷了指數成長，而指數成長對架構決策並不好。支援 1996 年 eBay 的正確架構不會是支援 2006 年 eBay 的正確架構。1996 年的架構無法處理 2006 年的負載，但 2006 年的版本對於 1996 年的需求來說過於複雜，無法建置、維護和演進。

事實上，這項準則可以融入組織的工作方式中。在 Google，明確的規則是設計一個系統，以滿足其目前需求的十倍，這意味著如果需求超過一個數量級，通常最好從頭開始拋棄並替換 [1]。子系統每隔幾年重新設計和拋棄是很常見的。

的確，看到人們進入一個成熟的程式碼庫，卻貶低其效能或可擴充性的不足，這是一個常見的模式。但通常在軟體系統的早期，你不太確定它真正需要做什麼，因此重要的是更專注於變更功能的彈性，而不是效能或可用性。稍後，隨著使用者增加，你需要轉換優先順序，但讓過多使用者使用效能不佳的程式碼庫通常比其相反的情況好。Jeff Atwood 創造了「效能是一種功能」這個詞彙，有些人解讀為效能永遠是優先順序第 1 位。但任何功能都是你必須與其他功能比較的東西。這並不是說你應該忽略效能等事物，軟體可能會變得非常緩慢且不可靠，以至於毀掉一項業務，但團隊必須與其他需求做出困難的權衡。這些通常是商業決策，而不是技術決策。

那麼，刻意選擇犧牲架構是什麼意思？基本上，這表示現在接受在幾年後你（有望）需要拋棄你目前正在建構的東西。這可能表示接受你正在組合的跨功能需求的限制。這可能表示現在思考一些事情，讓你在時間到來時更容易進行替換，軟體設計師很少思考如何設計他們的創作以支援其優雅的替換。這也表示承認在相對短的時間內被拋棄的軟體仍然可以提供大量的價值。

知道你的架構是犧牲性的並不表示放棄軟體的內部品質。通常，犧牲內部品質會比替換時間更快地咬到你，除非你已經在淘汰程式碼庫。良好的模組化是健全程式碼庫的重要部分，而模組化通常在替換系統時有很大的幫助。的確，使用系統早期版本可以做的最好的事情之一，就是探索最佳的模組化結構應該是怎樣，以便你可以根據該知識為替換建構。雖然在早期犧牲整個系統可能是合理的，但隨著系統的成長，犧牲個別模組會更有效，而這只有在你擁有良好的模組邊界時才能做到。

在處理這個問題時，有一件事很容易被忽略，那就是會計。是的，真的，我們遇到過人們不願意替換明顯不可行的系統的情況，因為他們攤銷程式碼庫的方式。對於大型企業來說，這更有可能成為一個問題，但如果你生活在那個世界中，別忘了檢查它。

你也可以將此原則套用於現有系統中的功能。如果你正在建構一個新功能，明智的做法通常是僅讓你的部分使用者使用它，這樣你就可以獲得回饋，了解這是否是一個好主意。為此，你最初可以犧牲的方式建構它，這樣你就不會對你發現不值得全面部署的功能投入全力。

模組化可替換性是微服務架構的主要論點，但我建議將其用於犧牲架構時要小心。微服務暗示著分佈和非同步，兩者都是複雜性的推手。我已經遇到過幾個專案，它們在沒有真正需要的情況下採用了微服務路徑，結果嚴重拖慢了它們的功能管道。因此，整體式架構通常是一個很好的犧牲架構，稍後再引入微服務以逐步將其拆開。

撰寫犧牲架構的團隊就是決定何時犧牲它的團隊。這與新團隊進來、討厭現有程式碼並想要重寫它的情況不同。對於自己沒有撰寫的程式碼，很容易在不了解其撰寫背景的情況下討厭它。明知故犯地犧牲自己的程式碼是一種非常不同的動態，而明知自己即將犧牲自己即將撰寫的程式碼，則是這種動態的一個有用的變體。