不在大型專案導入 React.js 的 5 個原因 關於跟著 React.js 一路成長的心得分享

不在大型專案導入 React.js 的 5 個原因

這篇文章會分享 5 個不建議在大型專案導入 React.js 的原因，主要內容皆從底下這篇文章翻譯而來，筆者的公司需要維護大型的專案，且部分情況需要和外包的工程師協作，專案開發的大致情境和背景:

• 220 個頁面，大概有 20% 需要高度客製化
• 需要顯示大量客製化的表格欄位類的資料
• 專案需同時讓多個團隊同時一起維護
• 會是進行多年的專案，且會一直加入新功能
• 不需要支援離線使用
• 公司較多 .NET 開發者

I almost got fired for choosing react in our enterprise-app.

接下來就來看看作者提出大型專案不該使用 React 作為技術選型的五個原因。

專案需要和 .Net 或是 Java 背景的開發者或外包廠商合作

可能會被問到底下幾個問題

• 相依性注入要怎麼寫? 我可以使用 InversifyJS 嗎?
• Functional Component 真的有比較好嗎? 我們還是寫 Class Component 吧
• 為什麼很多 function 沒有宣告成 static 封裝在 class 中
• 打 API Retry 的機制為何? 是否考慮用 PollyJS 來實作?
• 要怎麼使用 Visual Studio 把程式跑起來?

顯然在合作上，開發者會更傾向用原來已知的想法來學習和專案開發，像是 .Net 或 Java 的指導方針或是設計模式來寫 React，對於熟悉過去寫法的工程團隊來說，Angular 相對 React 也許會更適合當作大專案的團隊合作框架。

選了 react.js 後，需要花時間選擇更多第三方套件

因為 React 只是一個 lib 所以完整的專案就需要更多第三方套件，對團隊來說，從評估到使用的討論過程也會是開發成本。會遇到的問題像是:

• 要使用哪種路由?
• Redux 的非同步副作用要怎麼處理? thunk? saga? observable?
• 打 API 要怎麼實作? Axios? Fetch?
• 表單處理要用哪套? Redux-Forms? Formiq? Final-Form?
• CSS in JS 還是直接寫 SASS?
• i18n 的套件要使用哪套?

對團隊來說，引入或是拿掉函式庫都需要討論，需要去研究列出優缺點，確定對專案的影響範圍，至少，函式庫都要先玩過基本的功能。

也因為都是各團隊分開討論的關係，所以在大公司中，很可能不同團隊的專案會因為引入的函式庫而有非常不同的架構，也代表著換個專案就需要重新去學習。

React 進化快速，新寫法 (hooks) 後發先至開始主導市場

當專案開發到一半後，新的寫法卻明顯優於舊的寫法，於是工程師們就開始導入，所以就會出現同樣一種專案中混和兩種以上解決方案的狀態。改用新寫法後，另外一個問題就是新的寫法能夠和我們引用的第三分套件和諧的共處嗎?

舉例來說 react-redux 提供了更方便的 hook 就會造成原來的寫法和定義都不再適用? 不再去使用 connect 和嚴格的區分 container 和 component。

能確定下一個新寫法什麼時候出來嗎?

後期開發流程速度下降

當引入的套件越來越多，CI/CD 的速度也會越來越久，需要用到的硬碟空間也會越來越大。

因為 React 只是一個 lib，會引入越來越多第三方套件是正常的，問題發生點在於每個第三方套件各自引入的相依性套件又不太相同，會導致最後 \node_modules 資料夾肥大。

引入 Redux-Saga 這類工具反而讓專案更糟糕?

• 增加專案複雜度
• 當為了安全性、效能需要升級，但新的寫法出現速度很快，容易有升級上的成本
• React 的優點是簡單、彈性高且有豐富的生態系，卻也因為快速發展讓生態系出現了維護上的問題
• React 能夠向下相容，但較複雜的第三方函式庫卻可能無法

引入了一套穿透性高的工具後，會遇到的問題就是對陳年老專案來說就需要打掉重練，各位還記得 Flux 的 Alt 嗎?

• 為什麼只是套件升級要這麼花時間? (相容性問題)
• 為什麼開發效率越來越低? (因為要多花時間研究舊的套件，eg: Alt)
• 為什麼 bug 越來越多，穩定性越來越低?

結論與經驗分享

筆者這篇文章大多說的蠻中肯的，不過有些問題其實不完全跟 React.js 相關，早期在開發前端 SDK 的時候，前一個同事就是用寫 Java 的概念在寫 JavaScript，可以把 100 行能完成的寫法寫成 300 行，印象中那時候可以看到建立很多基本的 class 然後繼承又繼承後才變成可以用的功能。

小編之前有看過一個概念叫 YAGNI: You Ain't Gonna Need It. 在決定專案架構前，覺得可以問幾個問題:

• 真的需要使用 XX 模式嗎？
• 真的需要拆分成小元件嗎？
• 真的需要切成一堆小介面和抽象類別嗎？

在選擇 React 需要花時間選擇其他第三分套件的部份這的確是個成本，而且開源世界中很可能在某個階段作者說不維護就不維護這也是個風險。

過去我也曾看過團隊溝通協作可能不順暢的專案，在專案中類似功能都會有兩至三種以上的解決方案或寫法，這也確實造成了後續接手的我在開發流程速度下降的問題，因為在看程式碼的時候會充滿各種疑惑，更需要額外時間進行特定版本的函式庫寫法研究和考古，是到很後來才知道這是當時是把三個組的開發結果合併在一起的專案，也難怪充滿著許多前人的驕傲與不同的堅持。

關於引入過多的套件，我會覺得這倒是跟 react 無關，不過小編其實也曾經看過一個專案裡面共存 redux-observable 和 redux-orm，然而仔細看了一下需求，就可以感受到當時工程師想要嘗試新事物的心，但對後來的我大概只剩下賭爛，而 CI/CD 和本機開發速度也確實因為各種不同的套件引入受到影響，當時也因為筆電常常風扇快要崩潰的聲音所以整理函式庫，作法上就是能 CDN 的先 CDN，同樣功能不同套件不同寫法的想辦法整合，印象中 CI/CD 最後至少有少 30 秒。

YAGNI: 炫技跟過度結構化並不會讓專案變得更健康

• ← 上一篇
• 下一篇 →