美菜無線前端架構模型2018

胖弟弟：4年開發經驗，2014年畢業於北京大學智能科學系本科，曾就任美團、貓眼、有贊，現任美菜無線前端負責人。

美菜無線前端團隊：美菜大前端環路的一部分，團隊職能覆蓋「供應鏈——銷售——商城」相關的核心業務範圍，無線前端組是美菜前端開發實力和開發態度的表明。現階段無線團隊架構造成的開發範式，包含驅動模型和麪包板結構。

1、回顧美菜前端的發展歷史

2008-2018年國內前端經歷了改革開放般的短時間鉅變，十年時間，前端的職能顛覆，和其餘開發崗位有巨大差別，然而不少公司對於前端的認識還停留在過去或存在延滯。

美菜前端伴隨業務經歷過4年磨礪，從前端團隊的成立，到造成第一代架構，每兩年左右會逐步造成下一代架構的雛形。2018年上半年，無線前端組誕生，統一承接移動端技術棧和混合應用開發人員體系，美菜的前端正式進入3.0階段。

原始時代，1.0 階段，2014-2016

行業級框架 React、Vue誕生，彼時 Angular、YUI 、BackBone 等框架流行，但業內對待框架的態度相比如今更保守。熟悉框架的優質程序員缺少，大部分系統還須要後端參與前端代碼維護，先後端未分離。進入2015年，美菜已經產出了一套基於 jQuery 的框架及UI 組件庫，後期又封裝了基於Antd的SpruceJs。前端框架設計思路傳統，面向後端開發友好，部分解決了業務線劇增帶來的效率問題和職能配比失調的問題。

同時期，原生端，應用開始研發。移動Web端，基於 Zepto，逐步在多業務線展開開發，早期對於UI、頁面交互的標準不高，研發能夠主導產品的功能、交互，快速迭代。

農耕時代，2.0 階段，2016-2018

走向框架、走向先後端分離和模塊化分級。

2015年 React 優先發力，不少團隊已經躍躍欲試，卡在2016年入場選型的國內團隊，不約而同地把目光聚焦到 Vue。借住 Vue 的東風，美菜前端的 PC Web 端及移動 Web 端的框架統一。

業務井噴，迫於開發的敏捷需求，移動端走向混合應用。B2B生鮮領域在線下業務繁重，對終端的使用體驗提出了更高的要求，客戶在 APP 端的操做不可避免地多線、複雜，銷售人員也須要經過工具更快地觸達商戶，獲取最有效率、價值的工做任務。。。前端整個架構體系逐步完善，到了這個階段後期，框架選擇已經次要， 主要矛盾轉移到研發效率、項目穩定性、多平臺業務複用上。

咱們進入全面工程化的階段，一線開發人員同時是技術類產出的主要對象，高頻應對來自業務的直接壓力，既刺激開發人員的成長，也推進工做模式的優化。

機械時代，3.0 階段，2018

走出框架、走向業務，前端的思惟突破，多端、平臺化開發、一站式開發、業務模塊化。

端的人力分配差別逐步擴大，小中臺，強前臺。PC 端的業務從人力密集型走向技術密集型，提高自動化。中後臺的繁重業務經過模板系統解決。精細化運營訴求推進營銷系統也從運營人力導向轉向數據導向。

工程開發思想抹平框架差別，各類框架開發模式趨同化，過去大而全的前端框架的意識演化爲前端體系的一部分。前端的架構模型，變成麪包板模式（BreadBoard）。

前端開發更加專一到解決業務問題及平臺問題。開發人員在平常開發中沒必要要花費太多精力去進行基礎功能維護。團隊統一規劃專用、平臺化的業務層，避免重複工做。對於以前的一些焦點問題，變被動爲主動，進一步提高整個系統的反饋機制。

2、前端的早期表現

敏捷開發模式下誕生的團隊，不會套用過多流程，看上去很簡單，可是實際研發人員的精力很是分散。部門之間的規範是逐步造成的，對於一些線上 BUG，通常從老闆、投訴、測試那裏被動接收，系統在不斷打補丁。

平臺多樣化過程當中，對各個平臺技術棧的健全以及開發人員對工做棧的掌握程度提出了更多要求。框架差別化帶來極大的熟悉成本和人力成本是無心義的。本質上說，咱們要明白的仍是本身要解決什麼問題，框架能解決什麼問題。過去廣泛的認識是前端工具鏈在不斷變化，前端彷佛須要不斷學習新的工具使用，可是鏈路真的在變化嗎？

前端要解決的問題是在變異，不過是相對潛移默化的，框架的升級應該是量變到質變。原始開發階段的各種矛盾突出，一些「月經」場景：

場景分析

在工程化方面，咱們要解決的，說到底都是效率和質量問題。

當下前端工程化的產出，一部分仍是前端項目工程化，延續過去的路子，繼續在單人、團隊研發效率上鑽研，產出表現爲組件、開發工具，前端本身就能搞定，效率提高的的直接受益也是前端開發。另外一部分綜合服務，就須要多團隊，或者多功能人才的推進，不只能影響到更多團隊，也能反哺業務效率。

到了現代，不少系統的上線，僅僅靠前端的研發能力和推進力已經很難落地。這也是爲何不少前端團隊還長期停留在造一些小輪子，尤爲是 UI 組件方面輪子的窘態。但咱們不必放棄驅動，咱們關注是須要在架構的麪包板上插入什麼服務，而服務的上線，依靠的不只僅是你的代碼能力。

業務的不斷迭代和補丁式的維護狀態驅動着咱們的開發模式進行進化。

3、BreadBoard模型

2014年之前，移動端的市場地位還在攀升階段，咱們遇到更可能是瀏覽器端的兼容性、組件庫的完備性、頁面加載性能及 SSO 優化等問題。瀏覽器端雖然也會遇到差別性，可是開發模式相對統一，便於在公司內造成規範。而在移動互聯網大爆炸的時代，各路平臺的迅速興起，帶動了前端的裂變。多平臺，不一樣的語境狀況下，工程化要處理的問題更復雜。

美菜無線團隊的職能覆蓋了「供應鏈——銷售——商城」，除了後臺系統之外（咱們也有後臺需求），在業務鏈路上的精力已經被分散到9個端，多端複用的挑戰有：差別化管理、基礎服務複用、組件複用、頁面複用。

團隊框架的能力，已經脫離了大而全的時代，而進化到插件時代。過去咱們能夠用一套 Yeoman 解決問題，如今不一樣平臺光模板就得準備幾套。框架必需要升級的緣由：

1. 大而全的框架不可能知足全部團隊的需求、靈活性差，個性化定製也不可避免；
2. 傳統框架想解決的問題過多，指望初始化一勞永逸，而團隊的整個工做鏈路涉及到項目初始化的配置、開發過程、測試流程、上線發佈，可插拔的功能件需求更多；
3. 傳統架構模式依賴前端框架，前端框架的選型決定前端團隊架構模式，而目前的前端團隊應對的場景是多端，多平臺，前端框架退化/進化成團隊框架的一部分，框架不能決定架構，架構來吸取框架；
4. 開發要聚焦到核心業務邏輯，提高對核心業務邏輯的梳理能力。

框架理解

React、Vue 的爭議短暫存在過，兩年以前，團隊在框架選型、業務項目的基礎建設會浪費大量時間，項目之間的不可複用性極高。人員移動的學習成本極高。程序員對於 React、Vue 這些框架的定位認知有問題。現實是，若是不能更好地梳理項目的數據模型，無論使用 React仍是Vue，項目最終仍是會進入一個複雜的邏輯管理地獄（C 端）。因此引入框架，解決了部分問題，卻不夠根本。

整個團隊架構的升級根本依賴於對框架認識的升級，團隊的 MVVM 框架設計，基於對 Flux 的理解，React、Vue 的差別僅僅存在於 View 層面，以及所配套的一些生態鏈工具，他們所帶來的框架差別應該控制到團隊架構的一部分。

殼工具的理解

要抹平平臺之間的差別，同時在更小的範圍內作更細粒度的區分。前端的精力聚攏以後，向兩個方向分流，一部分是核心業務的理解和數據開發，一部分是工具鏈路的插件開發。

eg：基於ReactNative的新項目，過去的啓動成本極高，須要瞭解基礎的 iOS 項目啓動、安卓項目啓動，同時進行業務開發和公司服務接入。咱們開發React Native殼工程，下降精力分散，接入方早期學習成本僅 React（若是是前端，已是接近0成本），而由工程本生來對接公司的業務層邏輯和其餘工具。業務層能夠作哪些事情：

1. 專用業務層：首頁、訂單、搜索等三方業務層、掃碼、地圖
2. 平臺業務層：跨終端標準化接口、登陸、定位、地圖、分享、通知

4、驅動模型

開發的關注點在哪兒？團隊的核心是人，可是咱們一般的觀念是把關注點直接落到人的成長上。人在向公司，向團隊，要求成長和薪資。雖然這也是積極的模型，可是不成熟。我認爲我的和團隊的成長，說到底都須要歸結到具體的事情上，由事來驅動人，而你要作的事情，由驅動模型決定。

模型	特徵
補丁型	沒法實現判斷，緊急處理問題、解決、防止
防守型	指定預防策略、應對策略
進擊型	實施模擬對戰，和演練，線上模擬、壓力測試

補丁階段，監控的數據來源是哪兒？反饋、自測、領導?線上 BUG 就像暗處的敵人，不斷放冷槍。僅僅靠打補丁維護的系統，長期預期將會走向崩潰，因此要儘快進入防守型的狀態。

咱們須要完善整個防守的鏈路，這依賴於完備的監控體系。那監控到底要監控那些東西？

一個完整的鏈路須要包含監控、追溯、止損、預防。目前咱們已經將流量導向不一樣的系統：

1. 全量日誌的系統（負責總體性指標，如網絡可用性、埋點可用性）、
2. 個體日誌系統(提取個體用戶的關鍵信息，正對性分析客訴問題)、
3. 異常日誌系統（採集異常問題Crash、錯誤日誌）

一個防守雛形造成，可是作到完備的防守還有很長的路要走，目前能作到預警、能看到線上的 BUG，可是重現、定位、測試、上線的追蹤迴路過長，同時沒法找到一個用戶的行爲路徑，一個良好的線上行爲分析，還須要包括路徑分析：須要知道用戶在出現問題的時候的操做路徑、方法執行路徑（自動獲取）。所以咱們還有一些工做：

1. 主動測試
2. 客服等多反饋系統的迴流
3. 動態監控的迴流，能夠 push 觸及用戶，作主動回撈

5、Brief Summary & Future

工做流水線，全面模塊化、插件化，貫徹了咱們的開發階段。工程化的最大收益是精力的收斂，非聚焦模塊託管+監控，同時最大限度提高靈活性。Everything is plugin，咱們目前的插件化還僅僅是第一步。人力梯隊一樣採用麪包板，職能分工，同時展開流動。

短時間強前臺、小中臺，中臺承擔部分基礎建設功能，可是不會壟斷「架構」。咱們將來的工做重點要轉向更加高可用的框架體系：根據實際場景合理選型、預見以年爲單位的架構挑戰。

6、加入咱們

沒有一勞永逸的架構，也沒有徹底通用的架構，更沒有人叫架構師，每一個成員都有架構的角色。過去前端發展，借力於互聯網的發展紅利，而如今這個紅利期已經逐漸退散。前端是最貼近用戶的端口，前端工做的自然屬性，決定了大多數前端所在的公司不會直接重視前端崗位和團隊產出。即便短暫地由於技術痛點而獲得一些焦點，也沒法持久。前端團隊的出路在哪裏？一個前端人員的職業發展軌跡是否經得住推敲？

三年之前，若是你是一個精通 React 的前端，在職場上很是吃香，而到了2018年，要求更多了，職業發展的要求更容易受到行業流行技術的影響，是由於門檻不高？是大多數的從業者缺乏競爭壁壘。技術人員自身發展模式的改變，改變技術爲單一載體。去僞存真，解決問題。

防守姿態的前端驅動模型已經沒法支撐一個前端人、一個前端團隊在將來的生存，由於工做效率的提高，不須要這麼多低價值的前端，也不須要企業去養一個低價值的團隊。一個進擊的模型才能支撐將來一段時間的成長基礎。

美菜無線前端團隊，是一個進擊的「巨人」，驅動技術的進步和業務的發展正不斷攀升，團隊成員和水平也在穩步前行，加入咱們，實現自我和團隊的共同進階。有槍剛槍，一塊兒吃雞。

原文連接： tech.meicai.cn/detail/55， 也可微信搜索小程序「美菜產品技術團隊」，乾貨滿滿且每週更新，想學習技術的你不要錯過哦。