後端暫無涉及，目前考慮到前端後期的拓展性手機端app、 開發效率、維護性、與後端配合等

近期參與開發過一個項目，30餘名後端，17名前端，1000餘頁面，1000餘介面。

前端所用技術為vue+vue-router+axios+elementUI。

說一下項目中遇到的一些問題和解決方案跟實際效果。

背景:這是一個後端主導，管理不扁平，大領導外行的項目，時間倒逼十分嚴重，團隊人員倉促成型，部分中途上車。公司要求kpi考覈，必須使用公司提供的svn環境。

1.協作相關問題

開發人員太多，時間很短促，前端leader基本疲於頂住領導火力，基本無力主持具體研發，只能大體把控進度。

方案:衡量任務量與時間後決定採用同一分支協作開發，每日提交更新，每次更新先整體同步，每次提交只局部提交，公共組件自建自維護，任何涉及全局的改動羣內提前告知，通過技術手段隔離模塊路由，任務分工盡量避免視圖層開發撞車，請求允許兩種，全局掛載和局部集中管理。

後端原型axure,設計qq羣文件夾psd，前端自傳藍湖，icon使用阿里的icon-font，介面文檔yapi。項目管理禪道，組內日更新騰訊文檔。

問題:無產品，原型由後端拼湊，產品較複雜，因為邏輯不自恰，後續開發中造成了許多爭執與返工。設計完全不懂產品邏輯，基本是小透明。大領導重視進度，讓前端自己評估時間，但不信任前端給出的評估，反覆多次，前期錄禪道任務花了很多沒必要的時間，任務分期，砍任務，追加人手，996，手段齊上，項目依舊延期。開發過程中領導很心焦，進度要求日更，每週要拉各組leader彙報進度，deadline不斷要求提前。

2.路由許可權問題

需求:將許可權控制到按鈕級別，高度自定義角色訪問許可權。每一個路由都可配置。

方案:利用require.context和export、import自動化註冊路由和組件。利用vue-router的導航衛士和addRoutes實現動態路由。利用vue的directive實現v-auth指令許可權。根據後端下發的許可權樹提取扁平許可權標識符，前端映射路由和按鈕，根據配置介面篩選動態載入路由，控制按鈕載入。

問題:領導不斷調整菜單內容次序，任務分期也在不斷追加新的路由，產生新的頁面，前端映射文件依賴後端介面更新，但前臺的更新過程較為繁瑣，新增標識符需一一對應，指令許可權需要局部開發人員自己根據許可權表一一添加。如同頑固小疾。早期還幹擾新註冊路由的載入，後優化調整邏輯後解決。

3.代碼規範與質量問題

全局常量大寫加下劃線，局部變數與方法小駝峯，配置eslintrc。

問題:基本上是能幹活就抓上車，良莠不齊，隨時翻車的感覺，在不斷施壓下基本沒要求寫注釋做優化，後續維護如同跳火坑。

4.依賴管理與打包

前期組員隨意按需引入依賴，後來出現棧溢出後，優化了webpack配置，利用webpack-bundle-analyzer分析後做了依賴去重跟分包。

5.部署問題

前期本地打包ftp上傳，後期測試更新頻繁，讓後端同事配置了jenkins。

奇葩問題:

1.任務中涉及遠程協作，對方後端組轉發一個國外商用系統的介面，不願意寫文檔，不願意處理轉發數據，說沒時間。導致前端對接困難，前端部分代碼成為火坑。

2.大領導週五開會，覺得進度慢就讓前端加班，最騷的是讓加到8:30，因為到9點要報銷餐費。後續遇上給客戶展示的時候就要求安排前端週末兩天加班。

所以大型項目的大部分的問題其實跟兩個主流生態都相對完善的技術框架無關，是你需要去解決很多代碼之外的由人造成的問題。

補充:

項目後續需要人長期維護的，但大老闆開了一半前端，讓剩下的一半在火裏煎熬，測試在不停地鞭策前端改bug.

該項目是toB類雲管項目，部分模塊因為技術難度天坑，部分模塊因為業務難度天坑，後續需求是針對不同企業出定製化版本，通用版本預計是招攬客戶，展示投標用。

結合最近的編程經歷，修改一下答案，希望能說的更加清楚。

本人是什麼平臺都寫的，對三大平臺都有一定經驗，可以一句話總結三大平臺開發體驗：

  1. Angular的極限面向對象處理複雜業務非常舒適，但是對於輪子兄弟極其不友好，沒有CDK你就只能抓瞎，一句話：高樓大廈，攀登不易。
  2. React的Hooks有很強的Hacky精神，零星幾個API，絕大部分需求皆可實現，一句話：步步為營，跬步千里。
  3. Vue的API數量適中，基礎設施完善，文檔友好，概念與Angular和React都互通，一句話：百家之長，指哪打哪。

至於開發大型後臺管理項目，這個其實有很多前置條件的，三大平臺的優勢其實和你開發什麼項目無關，和人員構成和項目資源纔是密切相關的。

Angular實際上是純粹的自頂向下，復用設計模式，Rxjs+事件驅動對人員要求太高，如果你的需求頻繁變更，並且有很多自定義的特殊需求，Angular應該就是和你無緣了。

但是如果你的產品經理能夠給到UML，甚至直接生成ts代碼，並且你對產品可用度要求極高，那Angular就是為你準備的。

反正大多數互聯網企業，說不定企業的命都沒有大公司的一個大型項目週期長，沒必要對「前端」這個領域有這麼高的可用性要求。

類似AD這樣的產品，都是本身工業化程度非常高了，分工體系都遍佈全球了，纔有將「Angular」「附加「在其項目上的需求。

畢竟，谷歌的問題不一定是你的問題，就連谷歌自己，都不是每個項目甚至大多數項目都沒有這個需求，youtube，cloud，甚至AD的入口頁面，都用不到。

國內也就BAT，TMT的主營業務有這樣的需求吧？

React是純粹的自底向上，理論上來說，只要你能一層層封裝，開發應用就是點出來或者括弧出來的事。

但是，如果公司沒有基礎的UI庫，功能組件庫，從頭開始一點點往上爬，用React有點龜速。

當然，如果公司不擔心龐大的第三方庫的安全性的話，React也是可以的，只是這樣，和接下來要介紹的Vue，有什麼區別？因為封裝本身就會降低靈活性，遞弱代償。

React社區庫都有一個特點，越來越碎片化，比如react-router，material-ui，這麼做的原因是，大家都知道React的優勢就是自定義和漸進式，把粒度做小有利於用戶的二次封裝。

公司有自己的一套VIS，有出色的前端工程師，在前端領域有核心技術（比如圖形之類的），用React可以很好地陪伴公司成長，畢竟React本身只解決View問題。

其實用Angular配合React也是可以的，或者說，Angular對web component的支持是所有框架裡面最好的，一個module，注入服務，viewContainer，限定封裝方式，就可以辦到，理論上是這樣的。

React的關注點是函數，而Vue是組件，領域沒有React那麼小，但也沒有Angular的Module那麼大，正好是個折中方案。

基於component的封裝和渲染，使得製作Vue庫的複雜度比React稍高，但是卻比Angular輕鬆，好消息是很多庫都有官方方案，因此無需自行封裝。

對JSX的支持又使得其對兩種開發範式都有支持，比如很多UI庫，尤其是不那麼早期的，比如iView，vuetify，都是採用JSX或者render開發的。

所以Vue特別適合基礎設施差的公司，國內大部分公司的前端建設都屬於起步階段，採用Vue是非常合理的，這也和Vue大熱的現狀不謀而合。

總結來說，選什麼技術和你開發什麼項目關係不大，應該更多考慮公司現狀和個人現狀。

但是，學什麼就有點重要了。

像Angular這種框架，他剛出的時候我是非常興奮的，經常給人推薦，給人講解，但是後來才發現，講解太多領域驅動，設計模式，響應式函數式之類的概念，用不到，也是抓瞎。

技術和需求不匹配，就有點炫技的味道了，用不到某項技術，其實有可能是公司的問題和自己個人的問題，問題不應該出在技術上，畢竟Google已經驗證了這套技術的有效性，甚至本身就是為瞭解決Google遇到的問題而被開發出來的。

但是，學過和沒學過差別非常大，學過Angular，理解了面相對象的使用和封裝方式，以及ts的運用，體會到了interface，class等幾種類型聲明的利弊，你就不會說出像：有了ts開發體驗都一樣的話了。

運用Angular的概念，可以很容易地在其他平臺寫出優雅的業務代碼，工作會更加輕鬆。

同樣，運用React的概念，涉及到渲染細節的問題是，你也不會兩眼抓瞎。

Vue的定位和當前的市場環境決定了，國內大概率會走向大規模運用Vue的情況的，但是產業會升級，如果技術平臺不能改變，那就是靠提高人員素質的方向發展了。

Vue借鑒了Angular和React平臺的很多概念，如果你兩Angular和React基本理論都不熟悉，能夠靈活運用好它麼？

Vue今後會怎麼發展？

React的async render和hooks應該會得到運用，這個是個大概率的事情，Vue3已經證實，畢竟現在的props機制對typescript極其不友好，性能瓶頸也和16.8以前的React近似，但是Vue依舊會保留自己的核心競爭力，將領域定位在component一級，而不是React的函數。

Angular的HTML+也將會成為Vue的發展方向，Vue的模板可編程能力還是太弱了，不管是給編輯器集成一個languageService，還是模板中直接寫模板引用變數，都應該得到支持。

所以，你以為學一個框架就夠了？實際上是，每個框架都是必須的，沒有一個繞得過。

沒用過vue開發，用過react+antd，個人結論就是一定要選一個團隊leader熟悉的，團隊leader不熟悉起碼得有一個大牛支撐，沒有大牛那你自己得頂事纔行，要不然遇到問題真的是很讓人頭大！

我上一個項目的後臺大概是六個功能模塊，300多個頁面，業務邏輯面向製造業，項目週期大概8個月的時間，其中去掉收集需求，業務評估，技術選型這些亂七八糟的消耗，真正開發時間大概5個月左右。

前端技術棧選的就是react全家桶+antd，框架是一個第三方開源的小框架（沒用antd pro）。我本人是負責業務組件的封裝還有其中一個模塊的編寫，從業務上來看，製造業的後臺有的頁面著實簡單，大部分都是一個頁面一張表，或者一個表單完事了。但是儘管這樣，我們的項目還是出現了開發延期，部署困難等各種問題。

首先從技術選型上面來講，我認為leader根本就沒考慮團隊成員的承受能力。他本人完全屬於後端技術棧，不要說react，他連JS懂的都不多，而團隊裏也沒有用過react的，你說這是嘗試還是在瞎搞呢？開發使用的框架頁面是一個不知道從哪找來的第三方的，這就導致你想針對業務進行框架修改，不知道動了哪了，頁面就崩了，出了問題也沒個提issue的地方。項目上除了要開發自己的頁面，還要針對框架bug各種修修改改。

然後在開發初期，我們要封裝業務組件，也就是基於antd封裝項目頁面上要使用的各種table，form之類的，我認為我們沒有做好三點：第一是業務邏輯整理的不規範，導致我們封裝的業務組件根本無法適應多數頁面的使用，前期封裝了各種組件，從未參與過評審，到了後期真正開發頁面的時候，他跟我們來一句：」你這完全沒法用！「；第二就是過度封裝，leader要求盡量少寫jsx，table之類的組件傳遞一個對象的props就能完成各種邏輯的程度，這種想法在初期封裝沒什麼大問題，然而到後面真正300多個頁面開始用的時候，就發現哎呀，改起來太難了，基於class封裝的組件，業務邏輯復用起來真的好難，前面說了團隊沒有大牛，只能硬著頭皮嘗試改，改到最後我都不想看自己寫的組件了；第三就是沒有整理規範的組件文檔，給後期頁面開發造成了很大困難，前面改了什麼props，後面自己都不知道了（捂臉）。

最後是頁面開發階段，我們完全沒有做好團隊的協作。6個模塊沒有拆分，導致頁面熱更新真的超級慢啊！而且每次pull代碼都要解決衝突！並且沒有上CI/CD，還專門挑一個人出來做部署的活，每天早上8點，下午6點，固定提交代碼+build，花5分鐘改一個bug，然後15分鐘build，再10分鐘用於代碼上傳。。。簡直噩夢！

作為三大框架，這幾年都用過的傢伙來說一句，個人覺得做大型後臺管理系統來說，我個人覺得最規範的是ng，尤其是越複雜的用ng你就知道好處了。

Ng的好處就在於所選用的技術棧，跟後臺語言幾乎沒啥差別，一些概念基本相同，寫代碼的方式前後臺差不多，變數類型固定，不會像原生Javascript一樣奇怪。

但是，學習曲線陡峭，很多東西很抽象。

就Vue 和react來說，對於我們國人來說，vue 很容易上手，封裝的很好，實用傻瓜式，比較輕，對於小項目來說很友好。

當我剛開始用React的時候，覺得這哥們怎麼長得這麼奇怪，js裡面寫html，沒有像vue和ng裡面的遍歷方法，如ng-for，*ngFor，v-for指令，用最原始的map方法等遍歷html，然後書寫靈活。如果書寫習慣不好就會造成，代碼看起來特別的亂。

但是，當你寫熟了，你就會發現React真的好用，它的設計理念在於，一個插件只能做一件事情，而且同一件事有多種解決方式，相當的靈活，生態系統完善，那塊模塊有問題，去掉插上其他的。它的靈活性和規範性是可以根據開發者自身控制的，真的很人性化。

如果讓我個人來說，做手機端的話我會拿vue，如果做大型後臺管理系統我一定選React，關鍵太好用了。靈活易操控，模塊管理方便。

肯定是angular啊，真香

推薦閱讀：
相關文章