本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。

今天是2018年夏天。我的老板阿德里安(Adrian)請我與加拿大一家大公司的首席技術官詹姆斯(James)一起進行Skype通話。

在相互了解的同時，我發現詹姆斯是一個有雄心壯志的聰明人。他的愿景是將大規模的桌面WPF應用程序遷移到云中的Web。

我喜歡他的友好態度，可以說出他渴望與我們合作。他已經在印度擁有開發合作伙伴，但是他們缺乏構建Web應用程序的經驗。

我和Adrian在這種情況下遵循標準方法。我們還有幾個電話，然后我們開始發現階段，在此階段我們試圖把握全局并找到非功能性需求。這些是我們應重點關注的要點：

一個大型應用程序-超過220頁，其中大多數是維護屏幕，其中大約20%是高度定制的。

顯示大量數據，尤其是在具有各種功能的網格中：分組，列凍結，行擴展，自定義列，即可為其命名。

模塊化架構，允許多個團隊同時處理項目。

多年項目。新功能將隨著時間的推移而增加。

不需要離線支持。

為新團隊成員快速入門，特別是對使用舊桌面應用程序的.NET開發人員而言。

作為一名架構師，我的任務是創建一個技術提案，其中包含架構細節，方法，路線圖，指南，最重要的是將要使用的技術棧。

James多次提到他想要一種面向未來的技術，他不贊成Angular，因為在AngularJS被棄用之后，它的聲譽很差。

我已經使用Angular和React成功地實現了一些中小型項目，因此我對其中的任何一個都沒有真正的興趣。我覺得任何一個都能勝任。

對于這個項目，我選擇React with Redux…兩年后我會后悔的。

我們指定了一個由三名開發人員組成的團隊來進行概念驗證，兩個月后，它成功了。超級響應的用戶界面，超快的構建時間和高開發速度。每個人都很開心。

障礙1：.NET開發人員加入團隊

經過概念驗證后，是時候讓客戶外包團隊的開發人員加入了。我們還沒有開始知識共享會議，CTO給我發送了一封電子郵件，說：“嘿，拉茲萬。我們真的必須明天與我的外包團隊見面。”

我們開會，技術負責人向我提出問題和解決方案：

“依賴注入在哪里?“不需要一個是什么意思?”這是一個：InversifyJS!

“功能組件?不不不。我們不喜歡他們。讓我們使用類組件!”

“為什么這些函數只是四處徘徊，為什么不將它們封裝在服務類中以使其靜態化?”

“ API的重試策略在哪里?讓我們使用PollyJS實現一個。”

“當類名是PascalCase時，為什么文件名會變成破折號?它應反映類名，因此從現在開始，我們將其命名為SomePageComponent.tsx。”

而且，最讓我煩惱的是：“如何使用Visual Studio而不是Visual Studio Code運行它?”

對我來說很清楚他們想在React中使用.NET準則和設計模式。我已經多次看到這種情況發生-開發人員很難適應新技術的工作方式。因此，我不害怕就為何這些是React的異常模式展開辯論。

但是在這種情況下，CTO支持他的團隊，這很正常。在與團隊合作多年的時候，他認識我只有兩個月。我必須做出讓步，并同意他們的建議。

我剛剛意識到React不是Java或.NET開發人員友好的。由于類似的設計模式，在這種情況下，Angular會是更好的選擇。

障礙2：永遠只有React

React是一個沒有觀點的庫，這意味著它對如何實現跨領域關注沒有意見。因此，您和您的團隊有責任就如何使用它，尤其是要使用的其他庫提出意見。當然，您將使用第三方庫，因為您不想重新發明輪子。在React中，有很多選項可供選擇。

對于概念驗證，我已經對如何處理大多數跨領域問題有意見。現在，他們必須與新的團隊成員一起重新驗證。這是討論的基本主題列表：

應該使用哪個路由器?

除了Redux，異步動作還應該使用什么?Trunk?Saga

我們應該使用Axios還是訪存瀏覽器API?

Redux-Forms，Formiq還是Final-Form?

樣式組件，makeStyle，SASS還是純CSS?

國際化庫?

因此，我們又花了三個星期來做出這些決定。我可以感覺到您對我尖叫：“快點，伙計!不可能花三個星期的時間來挑選那些庫!”

好吧……歡迎來到企業項目。有很多決定。對于每一項，您都必須創建決策標準，進行研究，通過創建概念證明來驗證發現，提出發現，在決策日志中記錄所有內容以及使庫保持最新。這花費了瘋狂的時間，而且甚至沒有樂趣。

而且，我什至沒有考慮每個開發人員花費在學習所有這些第三方庫上的時間。我從未見過兩個具有相同依賴項，項目結構和準則的React項目。這意味著知識無法在項目之間轉移，就像在Angular或Vue中一樣。

在實施功能用戶故事方面未取得任何進展的三周后，CTO開始擔心。

障礙3：React Hooks受歡迎

九個月后，我們創建了50多個頁面。開發人員注意到功能組件與類組件一樣好，并開始使用它們。因此，現在該項目不再遵循原始的編碼準則。對于每個開發人員來說，這更像是個人選擇。對我來說，那沒關系。

React Hooks已發布并廣受歡迎。球隊有百感交集。有人認為類會使人和機器混淆，有些開發者對此感到不滿，而另一些人則熱衷于新的編碼模式。

我們正在使用的所有第三方庫都增加了對Hooks的支持，整個React世界似乎都朝著這個方向發展。那我們該怎么辦呢?我們是否應該偏離原始的編碼準則，并添加實現組件的第三種方法?無法退回并將現有頁面和組件遷移到Hooks!

該團隊贊成使用Redux Hooks，因為不需要使用Redux connect()并將轉儲組件與容器分開。這是有道理的，我們同意從現在開始，新頁面和新組件將使用Hooks。我們將保留舊的。

這就是我們最終得到三種處理方式的方式。不再有一致性。

更糟的是，一些開發人員開始提出不再使用Redux而是使用useState的想法。這意味著我們將破壞擁有一個單一全球狀態的想法。

懸念仍然是實驗性功能。我擔心它發布后會發生什么。

障礙4：開發放緩

當我們進行持續集成的設置時，構建大約花了三分鐘，包括npm安裝。但是現在，一年后，大約需要15分鐘。

我們還必須配置Node.js以將RAM擴展到4GB，因為2GB不夠了。這不是大問題。令人擔憂的是，開發人員已開始抱怨構建時間太長，在45-60分鐘的開發后熱加載就停止工作，并且重新啟動要花5分鐘以上的時間-特別是對于那些使用Windows機器(顯然是Linux系統的用戶)對于Node.js來說要快得多)。有時，他們不得不完全刪除node_modules并再次下載依賴項，因為否則它將無法正常工作。

當node_modules中有1200多個依賴項，總大小為600MB時，您會期望什么?

對于企業應用程序，一切都與成本有關。假設開發人員每天必須以每小時$ 40的速度重新啟動六次。六次/天x五分鐘x 240天/年x $ 40 /小時x八個開發人員= $ 38,400 /年對于企業而言，這并不是一筆大數目，但是對于項目發起人來說，這是一筆不錯的年度獎金。畢竟，它等于全新的Tesla Model 3。

障礙5：Redux-Saga快死了

大多數開發人員不同意我的觀點，但是我認為大部分業務邏輯都在Redux異步操作內部。在大多數情況下，它是唯一可以進行驗證，API調用，錯誤處理，觸發redux突變或觸發通知烤面包機的地方。如果不將這些視為前端應用程序上的業務邏輯，那又是什么?

我們使用Redux-Saga，這是一個糟糕的決定，因為它增加了不必要的復雜性。Thunk足夠好了。

在企業應用程序中，您必須不時地升級并重新驗證依賴關系。這是一個好習慣，因為您希望安全更新，性能改進和較小的增量API更改，同時希望不進行重大更改。看來Redux-Saga已落伍。上一次更新是一年多以前的，而沒有任何人修復它們，GitHub問題的數量仍在增加。

開發人員喜歡React的原因有三個：簡單性，靈活性和生態系統。React的團隊喜歡嘗試新的想法，但這正在破壞生態系統!他們應該勇敢承擔責任!

實際上，React大多是向后兼容的，但是React周圍的生態系統卻不是。開發人員和第三方庫將始終使用最新的功能和體系結構模式，而舊的實驗將被淘汰。對于中小型項目，這應該不成問題，因為您可以更輕松地進行調整。但是對于大型的多年項目，這些實驗可能會破壞交易。

已經是2020年9月，我決定將React-Saga納入技術指導委員會的風險評估結果中。

因為30%的業務邏輯都在saga中，所以我將其標記為高風險。那是當我們開始項目時，首席技術官發脾氣，并責怪我做出了錯誤的決定。

這只是產品經理需要的火花。他以此為契機開始提出如下問題：

“為什么我們必須花很多時間來升級庫?”

“為什么發展放緩?”

“為什么應用程序變得有bug和不穩定?”

事情升級到管理層。我花了很多時間尋找證據來證明我們當時做出了最好的決定，而不是我想度過周末的方式。

幾次回顧會議之后，我們再次駛過平靜的水面。畢竟，該項目即將完成。即將進入維護模式。

結論

我愛React。我將其用于我的所有個人項目，并希望將其推薦用于新的工作計劃。但是，在經歷了令人不愉快的經歷之后，我將不鼓勵將其用于企業應用程序。再沒有。

順便說一下，我并不孤單。

原文鏈接：

https://medium.com/better-programming/i-almost-got-fired-for-choosing-react-in-our-enterprise-app-846ea840841c