React 大型專案的 5 個痛點反思 從技術選型與團隊協作看挑戰

為什麼 React 可能不適合大型企業級應用？

React 企業級應用 的核心挑戰在於其「高度靈活」導致的「架構碎片化」。在進行 大型專案前端選型 時，不建議過度依賴 React 的理由包含：1. 協作成本高：缺乏強規範，導致跨技術背景團隊（如 Java/ .NET）難以快速上手；2. 選型負擔：開發者需自行組合狀態管理、表單、路由等工具，增加隱形成本；3. 前端技術債：技術演進過快（如 Hooks 取代 Class），造成程式碼風格不一。相比之下，React vs Angular 比較 顯示 Angular 的內建 DI 與嚴格規範更適合高品質的 軟體架構設計。遵循 YAGNI 原則，避免過度工程化，才是維持大型專案長久生命力的關鍵。

在現代的軟體開發中，React 企業級應用 已成為許多團隊的首選。然而，強大的工具並不一定適合所有場景，尤其是在處理極具規模的 大型專案前端選型 時。

這篇文章會分享 5 個不建議在大型專案導入 React.js 的原因。內容取材自國外資深工程師的實戰觀察，並結合我自身在維護複雜專案時的心得。我們將探討在擁有 200+ 頁面、需多團隊協作且生命週期長達數年的專案中，React 可能帶來的潛在挑戰。

參考原文：I almost got fired for choosing react in our enterprise-app.

大型專案不建議使用 React.js 的五個原因

1. 跨技術背景團隊的協作難度：React vs Angular 比較

當專案需要與 .NET 或 Java 背景的後端開發者或外包廠商合作時，React 的靈活往往變成了一種負擔。這類開發者更習慣物件導向 (OOP) 的設計模式，可能會問：

• 「相依性注入 (DI) 要怎麼寫？」
• 「為什麼不把邏輯封裝在靜態類別 (Static Class) 中？」

在這種情境下，大型專案前端選型 若考慮 Angular，其內建的強規範與 DI 機制可能比 React 更能降低溝通成本。

2. 碎片化的生態系增加技術選型成本

React 本質上只是一個 UI 函式庫，而非全功能框架。這意謂著團隊必須花費大量成本在挑選第三方套件上：

• 狀態管理：Redux, MobX, 還是 Zustand？
• 非同步處理：Thunk, Saga, 還是 Observable？
• 表單處理：React Hook Form 還是 Formik？

在大型公司中，不同團隊可能會選用完全不同的組合，導致 軟體架構設計 碎片化，工程師跨組協作時需重新學習，增加了隱形的開發成本。

3. 技術演進過快引發的「前端技術債」

React 的進化速度極快，例如 Hooks 的出現後發先至，迅速成為主流。這導致開發到一半的專案會出現「新舊寫法混雜」的狀態。當新的最佳實踐出現後，原有的 Class Component 或高階元件 (HOC) 寫法就成了 前端技術債，後續維護與升級的成本非常驚人。

4. 專案膨脹導致開發速度下降

隨著功能與第三方套件的堆疊，node_modules 會變得異常肥大。這不僅增加了硬體成本，更直接影響了 CI/CD 的建置速度。對於企業級應用而言，緩慢的編譯與部署流程會嚴重拖慢產品的迭代節奏。

5. 高穿透性工具 (如 Redux-Saga) 的維護困境

引入穿透性強的工具（如 Redux-Saga）雖然能解決複雜異步邏輯，但卻讓專案難以回頭。當需要進行版本升級或面臨套件不再維護的風險時，陳年老專案往往需要面臨「打掉重練」的命運。這對追求穩定性的企業級專案來說是巨大的風險。

結論與資深工程師的經驗分享：實踐 YAGNI 原則

筆者認為，React 的優點是簡單、彈性高，但這也正是它在大型專案中的雙面刃。在決定 大型專案前端選型 前，我建議先思考 YAGNI (You Ain't Gonna Need It) 原則：

• 我們真的需要這麼複雜的模式嗎？
• 炫技與過度的抽象化真的能讓專案更健康嗎？

前端技術債 往往來自於開發者想要嘗試新事物的心，卻忽略了長期的維護成本。我曾處理過混和了多種狀態管理方案的專案，CI/CD 的建置速度非常緩慢。透過移除冗餘套件並整合寫法，最終至少節省了 30 秒的建置時間。

在 React 企業級應用 的路上，保持架構的簡潔與一致性，遠比追求最新的技術趨勢來得重要。

FAQ：React 企業級應用常見問題

Q1：React vs Angular 比較，對於大型企業專案該如何抉擇？

A：如果您的團隊規模極大（超過 50 人）、成員技術背景多元（包含大量後端轉前端），且專案生命週期超過 5 年，Angular 的「全功能框架」與「強規範」能顯著降低溝通成本。而 React 適合追求極致靈活度、快速迭代，且團隊具備高品質 軟體架構設計 能力的小型精銳團隊。

Q2：如何處理大型 React 專案中日益嚴重的「前端技術債」？

A：核心在於「增量重構」。不要試圖一次將所有 Class Component 轉為 Hooks。高品質的實務是：在開發新功能或修復 Bug 時，順手重構相關元件。此外，應建立團隊的「技術白名單」，嚴格限制引入新的第三方套件，並定期進行程式碼審查，確保風格統一。

Q3：實踐 YAGNI 原則對前端架構有什麼實質好處？

A：YAGNI 原則（You Ain’t Gonna Need It）能防止開發者為「未來可能發生的需求」撰寫過度複雜的抽象層。這能保持 node_modules 的精簡，提升 CI/CD 的建置速度，並降低新進工程師的學習門檻。記住，最容易維護的程式碼就是那些「沒被寫出來」的程式碼。

• ← 上一篇
• 下一篇 →