架構該追求完美一次到位？還是先做出可行版本？如果你也在思考這題，請先回答一個問題：面對一個高度不確定的新產品，你會選擇「一次設計好一切」還是「先做一個可改變的版本再說」？這不只是技術選擇，更是價值觀選擇。有些人相信完美規劃才能防止災難；有些人則相信，唯有速度才能在混亂中找到方向。
主張一：初期的架構，應該為「可改變」而設計
在我們開始一個新產品時，團隊內部總會有這樣的辯論：「這個架構是否能撐得住同時在線 10 萬用戶？」、「要不要一開始就做成模組化，避免之後重構很麻煩？」、「不怕慢，就怕一開始沒想清楚啊！」聽起來都很合理，但真正讓人卡關的，是這些問題背後假設「需求很快就會穩定」，而這往往是錯的。
新產品最常見的失敗不是「架構撐不住」，而是市場根本「沒人要」，因此面對高度不確定的產品，我們不追求一次到位，而是先做出可改變的版本，用速度換學習。有人相信完美規劃能防止災難，我們則相信可變性才能在混亂中找到方向，以因應快速變動的市場需求，如此便不算技術債。
主張二：把技術債變成「預期債」
我們當然知道技術債會來，只是我們不希望它是突襲，而是可預期、可掌控、能償還的。
我們允許初期先執行變通方案，只要能清楚定義「進展到什麼時候要還債」
我們允許初期的程式結構不完美，只要能確保「這段可以安全被重構」
我們接受會還債，但不能「動也不敢動」
換句話說，我們不怕簡陋，只怕難改。
技術不是一次到位，而是階段性對應問題的解法。我們的檢核重點通常不是：「架構完成了沒？」，而是：「這樣的架構還撐得住下一階段嗎？」
主張三：避免被「過早優化」綁住
在產品還沒穩定前就優化架構，往往會引發以下三個問題：
- 高估市場速度：根本還沒幾個使用者，就在為百萬用戶做自動擴容架構
- 低估需求改變：以為今天的需求明天也一樣，結果過兩週大改版
- 資源錯配：花太多開發時間做不會立刻用到的功能，影響了迭代速度
以金融線上課程影音服務為例，早期我們盤點需要開發的功能包括直播課、點播回看、課程與軟體的組合銷售包，並支援全球可觀看、境內外金流、折扣碼與分期付款等多種需求，甚至一度必須考量 “海外擴張後 DAU（Daily Active User 每日活躍用戶）成倍成長”、”多裝置觀看”、”A/B 實驗”、”推薦系統” 等技術需求。
但我們很快意識到：這些多屬不確定的未來假設，若當下就全面實作，等同把「也許會需要」誤當成「現在必須完成」，將造成過早優化與資源錯配。
因此，我們採取最小可行體驗的策略：先只完成「下單購買 → 取得授權 → 播放觀看」的閉環體驗，確保營收路徑打通與可觀測性到位；其餘功能則根據不同模組列入路線圖，並設定觀察指標（例如 DAU 日活躍用戶數、使用者地域分布、金流失敗率、不同銷售策略成交占比）來決定何時迭代上線，這種做法既未耽誤商業化節奏，還讓我們在真實數據下判斷投入優先序。有些最初討論的能力至今仍未全數開發，因為證據顯示暫無必要；而確有價值者，則在門檻達成時再投入，能換則換、能捨則捨，用可變性對沖不確定性，而非迷信一次到位。
CMoney 的做法：用架構支持「快速試錯」與「迭代升級」
我們的價值觀和我們的產品一樣，來自對「不確定性」的深刻認識，我們知道：沒有一套架構可以一勞永逸，最可怕的不是選錯技術，而是執著於「選對」技術。架構設計不是靠預測未來，而是靠「為改變做好準備」。
因此，我們在每個新產品開發時，選擇的原則是：
- 以「最小可行架構」快速上線
- 在每個里程碑都設計重新確認架構的檢查點
- 能換，就不要綁死；能捨，就別過度設計
在初期驗證市場反應的時候，我們用最簡單的資料庫方案，甚至寄生在原有的服務之下，沒有 做資料庫分片，也沒有在一開始就考慮高可用性。最重要的考量點是將來在數據層能否抽換為其他資料庫，因此當確認使用人數持續成長後，我們才加上資料副本讀取功能，以及將資料庫遷移到 PostgreSQL、加上資料分片分表。
這不是隨便做，而是有意識地選擇「先求能改，再求完美」。
給所有在思考架構設計的人：一個實用的判斷原則
在架構設計時，問自己三個問題：
- 這個架構是否能快速改變方向？
- 這個設計是否有準備好面對未來不可預期的變化？
- 這筆技術債是可以預期、可控制、能還的嗎？
如果三題都答「是」，那就上吧！真正的穩定來自快速變化下的穩定機制，不是一次設計完成的「永遠」。我們追求的不是一次到位的完美，而是在快速變化中保持可變更的穩定。
在 CMoney，架構不是產品成功的保證，而是讓產品「能快速走對方向」的工具。我們的團隊、文化、決策方式，都是圍繞這個核心原則，與其預測未來，不如讓自己隨時準備好迎接變化。如果你也相信這一點，歡迎來聊聊，不論你是工程師、PM、或技術主管，這會是一次不一樣的對話。
了解 CMoney 職缺：https://cmy.tw/00BS0u