技術選型如果挑選最新、最酷炫的技術，很可能會踩到陷阱。一個真正好的技術決策，不只是從技術本身出發，更要將業務與團隊納入考量。

只考慮技術，可能會選到一個華而不實的方案；只考慮業務，可能會導致技術債堆積；只考慮團隊，則可能錯失技術紅利。我們需要能綜合考量這三個維度，做出最適合當下情境的決策。

維度一：技術層面

這是技術選型的基礎。你需要深度了解每種技術的優劣，並進行多方比較。

• 優勢與劣勢：這個技術擅長什麼？它的邊界在哪裡？例如：
• 避免過度設計：選擇技術不應只看它能做什麼，更要看它是否是解決當前問題的最小、最適合的方案。
• 長期維護：這個技術的未來發展性如何？維護成本高嗎？

情境 1：框架選擇

• React 擁有龐大生態系和社群支援，其靈活性讓開發者可以自由選擇路由、狀態管理等工具，但這也可能讓新人感到選擇困難
• 而 Vue 以其清晰的官方文件和內建方案著稱，讓開發者能更快上手，不過其新功能、新的 composition API 也增加了學習深度，彈性比 React 更大，不再像是過去人們所說 Vue 的學習成本較低。
• Next.js 則內建了多種渲染模式，能夠解決 SEO 和性能問題，但這份強大能力背後，也意味著其學習成本和複雜度會更高，需要團隊更深入理解 server side 與 client side 的運作。

情境 2：一個看起來很厲害，但卻不太適合的選擇

想像一下，你在公司初期的技術選型選擇了 Remix + XState + Recoil + Stylex 這個技術棧。這背後的原因可能不是技術需求，而是：

• Remix：因為它是目前 ChatGPT 在用的 meta-framework
• XState：因為狀態機的概念很酷，能讓程式碼看起來很優雅
• Recoil 與 Stylex：因為它們來自 Facebook，給人一種大公司技術的信任感。

這個組合初期可能不會有太大的問題，但是在隨著公司持續擴張之後，反而製造了巨大的認知負擔與維護成本。因為你需要花費大量時間來處理不必要的資料流、狀態機邏輯，以及可能在社群上找不到解決方案。

技術選型不只看技術的「亮點」，更要看其「暗點」。任何技術都有其適用情境，沒有所謂的「銀彈」。

維度二：業務層面

技術選型最終是為了服務業務目標。選擇一個技術前，必須先問自己：

• 解決什麼問題：這個技術能幫助我們更快實現業務目標嗎？它能解決當前業務面臨的痛點嗎？
• 時程與成本：這個技術的學習曲線長嗎？能否在未來公司擴張時，不會因為技術選型成為業務擴展緩慢的元兇。選擇過於複雜的技術或是冷門的技術，可能會導致開發與維護成本不必要地升高。

情境：自建 SSR 與框架的抉擇

如果你的業務高度依賴搜尋引擎排名，或是未來可能需要發展 AI Search 這塊，SSR 將是關鍵考量。此時，團隊會面臨一個核心決策：是使用 Next.js 或 Nuxt.js 等現成框架，還是自己從零實作？

有些團隊可能會考量到客製化需求，認為自行實作 SSR 解決方案可以更靈活。然而，資深工程師需要將此一決策視為一場總體成本（TCO）的權衡。

• 面對潛在的 Bug：自建的 SSR 解決方案在業務需求眾多時，若出現難以追蹤的 Bug，將會成為團隊巨大的認知負擔，嚴重影響開發士氣。
• 團隊擴張的成本：在公司與團隊擴張時，新進成員是否有能力與足夠時間接手這套自建的複雜架構？
• 長期維護：相較於由大型社群維護的框架，自建方案將所有維護、升級和除錯的責任都攬在自己身上，這份成本往往遠超過初期的開發時間。

選擇能夠讓團隊專注於核心業務邏輯的方案，而非將寶貴的人力投入到非核心的技術維護中。

維度三：團隊層面

任何技術的真正成本，都與人息息相關。資深工程師在做技術選型時，會從更宏觀的視角考量這個技術對團隊的長遠影響。

• 人才與入門成本：一個技術在市場上是否容易招募到人？如果團隊需要學習新技術，需要多少時間才能讓他們達到高生產力？這些都是影響專案總成本的關鍵。
• 團隊健康與士氣：選擇一個非主流或過於複雜的技術，會增加團隊的認知負擔，導致除錯困難、開發效率降低，甚至引發倦怠。反之，選擇團隊熟悉且有熱情的技術，能提升工作效率與士氣。
• 知識轉移與可擴展性：一個好的技術選擇，應該能讓知識在團隊中自由流動。若一個技術的知識只存在於少數人腦中，那麼它對團隊的長期發展是巨大的風險。這種風險，在工程領域有一個生動的衡量指標，叫做公車係數（Bus Factor）。

case：以 Lit 框架建構 Web Component 的情境分析

想像一下，你的團隊需要建構一個可被多個產品（包括使用不同框架的產品）共用的元件庫。從技術角度來看，Lit 框架和 Web Component 是個極具吸引力的選擇，它承諾了瀏覽器原生、輕量級且可跨框架重用的優勢。

然而，這項決策將在團隊層面帶來巨大的權衡：

• 人才與入門成本：相較於市場主流的 React 或 Vue，熟悉 Lit 和 Web Component 規範的開發者人才庫相對較小。這意味著未來的招聘會更具挑戰性，而新進成員即使有豐富的 React 經驗，也需要投入額外的時間學習不同的開發範式，才能達到高生產力。
• 團隊健康與士氣：雖然 Web Component 理念很好，但其生態系和工具鏈相對不夠成熟，除錯或遇到邊界問題時，可能需要花費更多時間自行解決，而不是從豐富的社群資源中找到答案。這份認知負擔會降低開發效率，甚至可能影響團隊士氣。
• 知識轉移與可擴展性：若團隊中只有少數成員精通 Web Component 的開發與維護，則會導致知識壟斷。這種風險，在工程領域有一個生動的衡量指標，叫做公車係數（Bus Factor）。

什麼是「公車係數」？

公車係數 (Bus Factor) 是一個衡量專案風險的指標，指的是「如果某位關鍵成員被公車撞到，導致他無法再繼續工作，專案會因此停擺或陷入困境的人數。」

這個概念的重點並不是詛咒某人，而是用一個生動的類比來警示團隊：知識不應該只集中在少數人身上。公車係數越低，代表專案的風險越高。

總結：沒有最好的技術，只有最適合的技術

資深工程師的技術選型決策，是一場需要平衡的抉擇。當你同時考慮技術、業務與團隊這三個維度時，你才能從眾多方案中，找出那個最適合當下情境的「最優解」。