架構師困境：選擇已被驗證的道路，還是自行開辟一條新路？

作者 | Pierre Pureur, Kurt Bittner

譯者 | 張衛濱

開發軟件就像一次旅行，在這個過程中，團隊需要不斷做出決策，既包括他們所構建產品的功能（即 MVP，最小可行產品），也包括支撐該 MVP 所需的架構（即 MVA，最小可行架構）。

采用這種方法的主要挑戰在于，我們必須足夠快速地構建出可發布的產品，以便團隊能盡快獲得關鍵反饋。

當團隊尋求更快捷的獲取反饋的方式時，他們必須決定，是選擇一條他人已經走過的路徑，還是另辟蹊徑、自行探索。

有一種重用架構的方式，那就是使用其他團隊已經采用的相同的平臺或框架。一個優秀的平臺或框架能讓每個團隊專注于自身獨有的“增值部分”。重復造輪子毫無價值，因此忽視現有的平臺和框架團隊，實際上就是在浪費精力，未能聚焦于只有他們自己才能完成的事情。

平臺和框架就像已經鋪設好的道路，它們能夠幫助團隊在開發旅程中更快地前進，并提供定義明確的“出口匝道”或擴展點，讓團隊可以在需要時對平臺進行擴展以滿足自身的需求。但它們也附帶一些副作用，可能使其變得不夠理想。

團隊需要針對如下問題做出判斷，即何時（如果有的話）應當離開他人鋪設的道路，通過擴展平臺 / 框架，甚至開發全新的平臺 / 框架，走出自己的路。

當團隊以平臺或框架作為其軟件架構的基礎時，所面臨的挑戰在于，選擇一條最接近其目標目的地的“鋪好的路”（即平臺或框架），同時盡量減少繞行或新建工程。但是，MVP 的問題是這個“目的地”在項目初期往往是未知的。

1 平臺和框架會替你做出許多決策，但其中有些是你根本不需要的

平臺和框架通常具有一定的傾向性，這意味著在構建 MVA 時，團隊需要做的架構決策更少。關鍵問題在于，團隊能否接受平臺開發者所做的那些決策？理想情況下，團隊應審視自身所需的架構決策，并與平臺已做出的決策進行對比。

這帶來了兩個重要的挑戰：

1. 團隊往往會在實驗獲得的經驗反饋中，逐步發現他們真正需要做哪些決策；

2. 平臺開發者所做的決策并不總是明確或最終的，尤其當平臺提供了擴展點，要求使用團隊自行填充代碼時更是如此。在“鋪好的路”這一隱喻中，這些擴展點正是團隊可以偏離主路、走上自己方向的地方。

許多平臺的決策是無害的，只要不影響團隊必須滿足的質量屬性需求（QAR），就可以接受甚至忽略。判斷這些決策是否會造成損害的唯一方法，就是通過實驗暴露平臺在哪些方面未能達成系統的目標。由于平臺開發者所做的決策常常未被記錄，甚至是未知的，所以團隊必須要測試他們的系統（包括所依賴的平臺），以確保架構目標（即 QAR）得以實現。

即使技術上可行，擴展平臺或框架也可能非常復雜。其他使用該平臺或框架的人可能不同意你所提出的決策及相關變更，或者他們可能更偏好其他方案，而這些方案又無法滿足某些團隊的實際需求。這也是為什么存在如此多功能相似的平臺和框架的原因之一。

此外，當團隊決定擴展某個平臺或框架時，他們實際上做出了一個隱含承諾，也就是長期維護這些擴展。他們必須將這種成本和所需的時間 / 精力納入決策考量。這包括未來升級應用以適配平臺 / 框架新版本的成本和工作量；若不及時升級，可能導致應用崩潰、安全漏洞無法修復，也無法利用新版本在性能和可擴展性方面的改進。

2 平臺和框架能節省時間，直到它們無法做到這一點為止

在我們的簡化視角中，平臺是指應用程序運行所使用的軟件環境（以及提供支撐的基礎設施），平臺的一個樣例就是 Amazon Web Services（AWS）?？蚣軇t是應用程序（或其一部分）部分完成的“骨架”，團隊在它的基礎上添加自身特定的業務邏輯，例如 Java Spring UI 框架。大語言模型（LLM）也可被視為一種平臺，團隊通過提示詞（prompt）對其進行擴展。平臺和框架通過提供大量現成的能力，簡化了應用程序的開發。

但有時候，團隊需要的功能與平臺或框架所提供的有所差異，舉例來說，LLM 可能無法處理團隊所需輸入類型，比如，需要處理電話通話的音頻并響應指令。LLM 在錄音室環境下表現良好，但面對在嘈雜的機場錄制的語音時，可能就無法工作。團隊需要先構建音頻降噪過濾器，但隨后可能發現這些過濾器仍不足以解決問題。此時，他們就不得不訓練自己的 LLM，以便使用包含“噪聲”的對話數據。

用“鋪好的路”作比喻，LLM 提供了一條已被驗證的路徑，但它無法帶領團隊抵達真正想去的地方。一旦發生這種情況，團隊別無選擇，只能在如下三種方案中做出選擇：嘗試擴展該平臺（如果可行）、尋找另一個平臺，或者從頭構建自己的平臺。

他們的挑戰在于，需要花費一定的時間才能判斷，究竟是基于現有平臺繼續開發更高效，還是必須為自己的場景構建獨特的方案。他們的選擇受限于平臺開發者所做的決策。如果能接受這些決策，那么基于平臺開發可能是最佳選擇；但如果不能接受，那么在此基礎上開發就是在浪費時間，而時間，恰恰是他們最寶貴的資產。

3 幫助厘清替代方案的三個關鍵問題

MVP 和 MVA 本質上是對潛在解決方案的“下注”。它們可能正確，也可能錯誤，而評估這些“賭注”是否成功的唯一方式就是實驗。以下 三個關于 MVP 的核心問題，有助于判斷平臺是否滿足你的需求：這個產品值得構建嗎？它能否在預期負載下實現可擴展性和性能？ 它是否具備長期可維護性？

圖 1：幫助確定架構決策的三個問題

團隊在評估某個平臺時，應結合這三個問題進行思考：

1. 該平臺有助于 MVP 的開發，還是阻礙 MVP 的開發？

   平臺可能提供面向用戶的功能，簡化 MVP 的開發，但也可能附帶團隊無法接受的架構決策。借用道路的隱喻來說，唯一的方法是先沿著這條路走一小段，通過架構實驗，檢驗平臺所做的決策是否契合團隊對 MVA 的需求。

2. 該平臺能否在預期的負載下實現可擴展性和性能？

   這里的難點在于，通常只有通過實驗，你才能真正了解自己的可擴展性需求。借用道路的隱喻來說，你往往并不清楚自己需要的是一條車流稀少的雙車道鄉間小路，還是一條能夠承載海量車流的高速公路。

3. 基于該平臺構建的架構是否具備長期可維護性？

   平臺的演進速度通常比具體的業務系統更慢，因為它們的變更往往需要社區共識。當平臺無法快速調整以滿足需求時，團隊就需要有明確的機制來擴展平臺，直到平臺本身能夠做出相應修改。

這些問題不應該僅僅停留在激發思考和討論的層面，必須通過實驗進行實證評估。在實踐中，這些實驗體現為可執行的測試，可以在系統構建過程中持續運行。頻繁對系統進行測試，以評估當前架構是否仍然適合目標用途，有助于避免后期出現不可控的大規模返工。

盡管上述三個問題看似按線性順序展開，但實際上它們構成了一個循環（如圖 1 所示）：針對性能 / 可擴展性和模塊化所做的調整，不應危及整體解決方案的有效性。

4 結論

平臺就像一條現成的道路，可以讓團隊在交付 MVP 的旅程中更加輕松，但前提是，這條路確實通往他們想去的地方。團隊在使用平臺時面臨的核心挑戰在于，至少在項目初期，他們并不完全清楚自己的目的地，因此也無法確定平臺所提供的“鋪好的路”是否能帶領他們抵達那里。

判斷這條道路是否適合其 MVP 的一個重要方法，就是先走一小段，看看方向是否仍然正確，而這個“正確的方向”，正是由團隊的質量屬性需求（QAR）所定義的。

最終，團隊不可避免地會在某個時刻離開平臺所提供的“鋪好的路”，走出自己的路徑。通過實驗，他們可以判斷何時、何地需要這樣做，是擴展平臺以滿足自身需求，還是開發平臺完全未提供的全新解決方案，甚至徹底替換掉原有的平臺。

The Architect’s Dilemma: Choose a Proven Path or Pave Your Own Way?(https://www.infoq.com/articles/architects-dilemma/)

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。