美菜無線前端架構模型2018
胖弟弟：4年開發經驗，2014年畢業於北京大學智慧科學系本科，曾就職美團、貓眼、有贊，現任美菜無線前端負責人。
美菜無線前端團隊：美菜大前端環路的一部分，團隊職能覆蓋“供應鏈——銷售——商城”相關的核心業務範圍，無線前端組是美菜前端開發實力和開發態度的代表。現階段無線團隊架構形成的開發正規化，包含驅動模型和麵包板結構。
一、回顧美菜前端的發展歷史
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）。
前端開發更加專注到解決業務問題及平臺問題。開發人員在日常開發中不必要花費太多精力去進行基礎功能維護。團隊統一規劃專用、平臺化的業務層，避免重複工作。對於之前的一些焦點問題，變被動為主動，進一步提升整個系統的反饋機制。
二、前端的早期表現
敏捷開發模式下誕生的團隊，不會套用過多流程，看上去很簡單，但是實際研發人員的精力非常分散。部門之間的規範是逐步形成的，對於一些線上 BUG，一般從老闆、投訴、測試那裡被動接收，系統在不斷打補丁。
平臺多樣化過程中，對各個平臺技術棧的健全以及開發人員對工作棧的掌握程度提出了更多要求。框架差異化帶來極大的熟悉成本和人力成本是無意義的。本質上說，我們要明白的還是自己要解決什麼問題，框架能解決什麼問題。過去普遍的認識是前端工具鏈在不斷變化，前端似乎需要不斷學習新的工具使用，但是鏈路真的在變化嗎？
前端要解決的問題是在變異，不過是相對潛移默化的，框架的升級應該是量變到質變。原始開發階段的各類矛盾突出，一些“月經”場景：
場景分析
在工程化方面，我們要解決的，說到底都是效率和質量問題。
當下前端工程化的產出，一部分還是前端專案工程化，延續過去的路子，繼續在單人、團隊研發效率上鑽研，產出表現為元件、開發工具，前端自己就能搞定，效率提升的的直接受益也是前端開發。另一部分綜合服務，就需要多團隊，或者多功能人才的推動，不僅能影響到更多團隊，也能反哺業務效率。
到了現代，很多系統的上線，僅僅靠前端的研發能力和推動力已經很難落地。這也是為什麼很多前端團隊還長期停留在造一些小輪子，尤其是 UI 元件方面輪子的窘態。但我們沒必要放棄驅動，我們關注是需要在架構的麵包板上插入什麼服務，而服務的上線，依靠的不僅僅是你的程式碼能力。
業務的不斷迭代和補丁式的維護狀態驅動著我們的開發模式進行進化。
三、BreadBoard模型
2014年以前，移動端的市場地位還在攀升階段，我們遇到更多是瀏覽器端的相容性、元件庫的完備性、頁面載入效能及 SSO 優化等問題。瀏覽器端雖然也會遇到差異性，但是開發模式相對統一，便於在公司內形成規範。而在移動網際網路大爆炸的時代，各路平臺的迅速興起，帶動了前端的裂變。多平臺，不同的語境情況下，工程化要處理的問題更復雜。
美菜無線團隊的職能覆蓋了“供應鏈——銷售——商城”，除了後臺系統以外（我們也有後臺需求），在業務鏈路上的精力已經被分散到9個端，多端複用的挑戰有：差異化管理、基礎服務複用、元件複用、頁面複用。
團隊框架的能力，已經脫離了大而全的時代，而進化到外掛時代。過去我們可以用一套 Yeoman 解決問題，現在不同平臺光模板就得準備幾套。框架必須要升級的原因：
- 大而全的框架不可能滿足所有團隊的需求、靈活性差，個性化定製也不可避免；
- 傳統框架想解決的問題過多，期望初始化一勞永逸，而團隊的整個工作鏈路涉及到專案初始化的配置、開發過程、測試流程、上線釋出，可插拔的功能件需求更多；
- 傳統架構模式依賴前端框架，前端框架的選型決定前端團隊架構模式，而目前的前端團隊應對的場景是多端，多平臺，前端框架退化/進化成團隊框架的一部分，框架不能決定架構，架構來吸收框架；
- 開發要聚焦到核心業務邏輯，提升對核心業務邏輯的梳理能力。
框架理解
React、Vue 的爭議短暫存在過，兩年之前，團隊在框架選型、業務專案的基礎建設會浪費大量時間，專案之間的不可複用性極高。人員移動的學習成本極高。程式設計師對於 React、Vue 這些框架的定位認知有問題。現實是，如果不能更好地梳理專案的資料模型，不管使用 React還是Vue，專案最終還是會進入一個複雜的邏輯管理地獄（C 端）。所以引入框架，解決了部分問題，卻不夠根本。
整個團隊架構的升級根本依賴於對框架認識的升級，團隊的 MVVM 框架設計，基於對 Flux 的理解，React、Vue 的差異僅僅存在於 View 層面，以及所配套的一些生態鏈工具，他們所帶來的框架差異應該控制到團隊架構的一部分。
殼工具的理解
要抹平平臺之間的差異，同時在更小的範圍內做更細粒度的區分。前端的精力聚攏之後，向兩個方向分流，一部分是核心業務的理解和資料開發，一部分是工具鏈路的外掛開發。
eg：基於ReactNative的新專案，過去的啟動成本極高，需要了解基礎的 iOS 專案啟動、安卓專案啟動，同時進行業務開發和公司服務接入。我們開發React Native殼工程，降低精力分散，接入方早期學習成本僅 React（如果是前端，已經是接近0成本），而由工程本生來對接公司的業務層邏輯和其他工具。業務層可以做哪些事情：
- 專用業務層：首頁、訂單、搜尋等三方業務層、掃碼、地圖
- 平臺業務層：跨終端標準化介面、登入、定位、地圖、分享、通知
四、驅動模型
開發的關注點在哪兒？團隊的核心是人，但是我們通常的觀念是把關注點直接落到人的成長上。人在向公司，向團隊，要求成長和薪資。雖然這也是積極的模型，但是不成熟。我認為個人和團隊的成長，說到底都需要歸結到具體的事情上，由事來驅動人，而你要做的事情，由驅動模型決定。
| 模型 | 特徵 |
|---|---|
| 補丁型 | 無法實現判斷，緊急處理問題、解決、防止 |
| 防守型 | 指定預防策略、應對策略 |
| 進擊型 | 實施模擬對戰，和演練，線上模擬、壓力測試 |
補丁階段，監控的資料來源是哪兒？反饋、自測、領導?線上 BUG 就像暗處的敵人，不斷放冷槍。僅僅靠打補丁維護的系統，長期預期將會走向崩潰，所以要儘快進入防守型的狀態。
我們需要完善整個防守的鏈路，這依賴於完備的監控體系。那監控到底要監控那些東西？
一個完整的鏈路需要包含監控、追溯、止損、預防。目前我們已經將流量導向不同的系統：
- 全量日誌的系統（負責整體性指標，如網路可用性、埋點可用性）、
- 個體日誌系統(提取個體使用者的關鍵資訊，正對性分析客訴問題)、
- 異常日誌系統（採集異常問題Crash、錯誤日誌）
一個防守雛形形成，但是做到完備的防守還有很長的路要走，目前能做到預警、能看到線上的 BUG，但是重現、定位、測試、上線的追蹤迴路過長，同時無法找到一個使用者的行為路徑，一個良好的線上行為分析，還需要包括路徑分析：需要知道使用者在出現問題的時候的操作路徑、方法執行路徑（自動獲取）。因此我們還有一些工作：
- 主動測試
- 客服等多反饋系統的迴流
- 動態監控的迴流，可以 push 觸及使用者，做主動回撈
五、Brief Summary & Future
工作流水線，全面模組化、外掛化，貫徹了我們的開發階段。工程化的最大收益是精力的收斂，非聚焦模組託管+監控，同時最大限度提升靈活性。Everything is plugin，我們目前的外掛化還僅僅是第一步。人力梯隊同樣採用麵包板，職能分工，同時展開流動。
短期強前臺、小中臺，中臺承擔部分基礎建設功能，但是不會壟斷“架構”。我們未來的工作重點要轉向更加高可用的框架體系：根據實際場景合理選型、預見以年為單位的架構挑戰。
六、加入我們
沒有一勞永逸的架構，也沒有完全通用的架構，更沒有人叫架構師，每個成員都有架構的角色。過去前端發展，借力於網際網路的發展紅利，而現在這個紅利期已經逐漸退散。前端是最貼近使用者的埠，前端工作的天然屬性，決定了大多數前端所在的公司不會直接重視前端崗位和團隊產出。即使短暫地因為技術痛點而得到一些焦點，也無法持久。前端團隊的出路在哪裡？一個前端人員的職業發展軌跡是否經得住推敲？
三年以前，如果你是一個精通 React 的前端，在職場上非常吃香，而到了2018年，要求更多了，職業發展的要求更容易受到行業流行技術的影響，是因為門檻不高？是大多數的從業者缺少競爭壁壘。技術人員自身發展模式的改變，改變技術為單一載體。去偽存真，解決問題。
防守姿態的前端驅動模型已經無法支撐一個前端人、一個前端團隊在未來的生存，因為工作效率的提升，不需要這麼多低價值的前端，也不需要企業去養一個低價值的團隊。一個進擊的模型才能支撐未來一段時間的成長基礎。
美菜無線前端團隊，是一個進擊的“巨人”，驅動技術的進步和業務的發展正不斷攀升，團隊成員和水平也在穩步前行，加入我們，實現自我和團隊的共同進階。有槍剛槍，一起吃雞。
原文連結： ofollow,noindex">tech.meicai.cn/detail/55， 也可微信搜尋小程式「美菜產品技術團隊」，乾貨滿滿且每週更新，想學習技術的你不要錯過哦。