680      美團網

美團旅行前端技術體係的思考與實踐

前言

今日早讀文章由美團@葉俊星授權分享。

正文從這開始～

為什麼要講這個題目

前端圈是一個被技術圈的人稱為娛樂圈的領域，很多做後端的、算法什麼的，會經常來調侃前端圈，知乎上甚至有個問題問「前端架構是什麼，前端有架構可談嗎？」，甚至前端圈自己也有很多人在自嘲。但實際上，這些年來，隨著互聯網的發展，前端也在迅勐地發展，前端的需求變得越來越複雜，前端團隊也不斷地變得龐大。在一個複雜的產品和規模比較大的團隊當中，如果說沒有架構，隻能說是手工作坊式地生產，效率太低。所以說，我特意選了這麼一個話題，來悍衛一下咱們前端的尊嚴：）

什麼是技術架構？

技術架構是指社會中各種技術之間相互作用、相互聯係、按一定目的、一定結構方式組成的技術整體。技術架構——或者說技術體係——歸根結底是圍繞業務發展、團隊規模和團隊特點量身打造的，它的最終目的是在確保線上的質量和穩定性的前提下，提升團隊整體的研發效率。

既然說，技術架構是圍繞業務發展、團隊規模和團隊特點來設計的，那我們就要先梳理一下我們的項目和團隊背景是怎樣的。我們美團點評酒旅的項目和團隊背景分別有這些特點：

項目的特點：項目之間差異中有相同。比如說 B 端和 C 端項目雖然麵向的對象不一樣，但是同樣是要做用構建、要做測試的；又比如 B 端頁麵雖然業務之間各不相同，但基本上都是查詢、表單和圖表這麼三種頁麵。如果說每個項目我們都重新地去做這些東西，效率就很低。所以，我們需要提高項目之間的複用率。

團隊的特點：規模大。光我們酒旅事業群前端就有一百多個人，並且還在不斷規模化，也就是說人在變得越來越多。那麼大家都知道，規模化就會導致溝通成本的提高，我們希望能盡可能地降低規模化帶來的成本上升，盡可能地固定規模化的成本，從而實現規模效應。

標準化

那麼基於這樣的項目和團隊的特點，我們可以很清晰的看到，我們最先需要做的，就是——標準化。標準化對團隊的本質是，我們要把整個團隊使用的各種技術進行約束，對選型進行劃分和收窄。

這樣的約束能夠給我們帶來很多好處。

對於項目來說，我們可以把各個項目可複用的部分抽離出來，通過標準化來提高它的複用率。比如很常見的一點，就是把組件庫抽離出來，使得這些組件可以在各個業務項目中複用；再比如說，我們把部署、監控等這些服務抽離出來，做成獨立的服務，提供給各個業務線來使用。所以說，標準化後的項目，我們不再需要做重複的技術選型工作，並且可以很方便地尋找各種公共服務來複用，最終實現最終提高效率的目的。

對於團隊成員來說，在標準化之後，項目無論是從選型還是所使用的公共服務來說，都幾乎是一樣的，所以不同項目之間人員的流動在技術上幾乎沒有成本，僅需要熟悉業務。還有，對於初、中級的同學來說，他們可以清楚地看到我們技術架構的全景圖，有明確的、清晰的需要掌握的技術棧可以去學習，從公司的角度來說，團隊在培訓和招聘時能夠也更能有針對性；對於高級人才來說，我們可以使得願意思考、有能力的同學，有更多的空間加入到技術架構的思考和優化當中，把成果貢獻到大團隊裏來，去影響更多的工程師和項目，從而獲得更大的收益，最終結果可以用乘法來計算。

那麼要實現標準化這個目標，我們就需要圍繞著這個目標去做設計。

這個就是我們美團點評酒旅團隊，在經過標準化之後，做出來的技術架構。我們可以看到，我們標準化的流程規範，會覆蓋到整個從開發到構建、再到部署、最終運行的工作流程裏麵去。

自動化

那麼有了標準化之後，我們就會發現到，有些環節它是機械重複的，我們是可以用工具、用機器去代替的。比如，我們有代碼規範，以及提交代碼時要進行代碼檢查的流程，那麼我們可以發現，進行代碼檢查這件事情，實際上是可以自動化的。我們用了 lint 工具，去做這種自動化的檢查。

自動化往往能成倍地甚至無限地提升我們在某個環節上的效率。

在我們團隊的技術架構圖中可以發現有基礎工具、自動化測試工具、部署平台、監控體係，這些工具和平台，這些都是我們在標準化之後發現可以用機器去取代人工而做出來的。我們舉兩個更具體一點的項目，來讓大家感受一下。

第一個例子的背景是，小程序慢慢開始普及，我們有非常多的小程序需求，而這些小程序的需求往往也有一套幾乎一樣的移動端頁麵，所以我們會發現我們在不同的平台做著同樣的業務，這是我們出現的機械重複的工作。於是我們投入了一些人力資源，去研究如何實現一套代碼同時在移動端頁麵和小程序頁麵，甚至 Native 中運行。那麼考慮了我們團隊整體是以 Vue.js 為主的，於是我們做了一個叫 mpVue 的工具，它做的事情就是，把 Vue 的語法轉換成小程序的語法，實現移動端頁麵可以完美地轉換到小程序的語法，實現了小程序的快速開發和多端複用，相比起之前我們需要工程師去學習小程序開發而言，有了這個工具之後，我們的工程師幾乎不再需要學習小程序的開發，從而接近無限地降低了小程序的學習和開發成本。在未來理想的狀態，我們可以實現一套代碼，直接在 Web 端、小程序端（包括微信和支付寶）以及 Native 端（借助 Weex）這樣多端上運行，write once, run everywhere。

第二個例子的背景是，我們的 B 端需求對界麵的要求並不高，僅僅需要滿足的是核心功能，而這些頁麵的相似性非常高，通常就是三類：查詢頁、表單頁或詳情頁，以及圖表頁。這些需求雖然說每個業務都不同，但是實際上我們幾乎都是在做同樣的事情，我們在開發這些頁麵的時候，實際上都是直接在堆標簽堆組件，無腦地去綁定數據，寫 HTTP 請求。那麼我們就在想，對於這些簡單機械的事情，我們是否能做得更快，甚至自動化？於是我們做了一個 IDE，這個 IDE 是基於 Vue 之上封裝的一個圖形化頁麵搭建工具，可以讓工程師通過拖拽的方式，迅速地搭建前端頁麵，並且支持數據綁定。使用這個 IDE 搭建頁麵是非常迅速的，我們這裏收集到的數據是，一些原本需要 1-2pd 去寫的頁麵，通過我們這個工具，隻需要 1-2 個小時，提升了 30%~80% 的開發效率。目前來說，我們已經能夠使用這個 IDE 搭建一些對頁麵要求不是非常特別的頁麵了，擁有了一個基礎的頁麵搭建能力。在這之後，我們會繼續迭代我們的 IDE，提供那三類頁麵的模板，甚至根據 API 文檔，自動地生成頁麵，使得工程師隻需要做一些很小的改動，就能完成頁麵的開發，進一步提升我們的開發效率。

除了從標準化實現自動化的這些好處之外，我們還會發現，當我們實現了自動化之後，自動化又會反向地去促進標準化。因為人的惰性或者能力的不足，有些同學可能會不願意去按照或者偷偷地不按照標準化來做，比如說很多人就是不願意按照代碼規範，在等號左右加空格之類的。那麼我們有了自動化檢查工具之後，如果說這些同學還這樣做，就會通不過自動化工具的檢查，通不過就無法提交代碼，所以他必須得按照我們的標準化的代碼規範去寫代碼，這樣他才能成功提交代碼。所以我們說，自動化雖然說是來自於標準化，但是他又會反向地去促進標準化的執行，是一個良性的循環。

前端工程師如何成長？如何進階成為美團點評中/高級工程師、技術專家？

那麼關於架構的方法論咱們就聊到這裏，接下來咱們來聊一下關於前端工程師成長的方法論。

我們說，其實我們做所有的事情，最後都會落到對人的影響上。打個比方，有一天我們做的項目的代碼全部都丟了，包括服務器所有人電腦和 git 倉庫都沒了，但我們的人還在，我們其實是可以很快地把這個項目重新寫出來的，而且會寫得更好。因為我們在做項目的過程中，所經曆的思考、所做的設計，最終都會成為人的經驗，這個才是最寶貴的東西。所以說，作為公司，最看重的是對人的培養。

反過來說，作為工程師自己，其實最看重的，也是自身的成長。有很多工程師——包括以前的我——也會遇到這麼一個階段，對自我的認識是這樣的：我能 hold 住所有的需求，我能夠靈活地運用很多的 UI 框架、構建工具、測試工具等等，我會函數式編程，我會響應式編程；還有些工程師會說，我的經驗比較多，業務比較熟練，我還帶著幾個人一起去做業務。但是大家心裏就還是有個問題，大家都意識到，在這個時候再深入挖掘技術，投入產出比並不高，比如我們可能可以花了很大的力氣去把 V8 的工作原理完全搞懂，把源碼全看過一遍，這樣做對我們來說，可能根本不會對公司有什麼幫助。但問題是，我們很迷茫，我們清晰地感覺到自己到達了一個瓶頸期，但是卻不知道怎麼突破這個瓶頸。

我自己當時在遇到這個問題的時候，我其實問了很多很多人，包括業界比較有名氣的 @賀師俊、@顧軼靈 、@小爝、@小芋頭君 等等，以及我的老大和我老大的老大等等，他們有的是走管理路線的，有的是走技術路線的，他們都從不同的角度給了我很多的經驗和指導。那麼接下來，我就分享一下，經過我思考和消化，結合我們美團的人才培養理念，關於工程師進階到技術專家的方法論。

對於我們前端工程師，甚至包括客戶端在內的終端工程師來說，要進階到技術專家級別，主要是從這三個方麵來入手：規劃、複盤和視野。當然除了這三者之外，還有再高層次的一個領域就是商業思維，我這裏說的商業思維指的是，我們對業務非常熟練，從最初的用技術支撐業務，到通過研究出一些更好的技術，來反向驅動業務的發展的能力。大家都很熟悉的一個例子就是人工智能。但這個能力在終端上並不是很容易做，所以我們主要關注的還是規劃、複盤和視野這三個方麵，它們是三個不同的方向。

做規劃

規劃是向前看，它是對未來整體性、長期性、基本性問題的思考和考量，設計未來整套行動的方案；用通俗的話說，就是實施總體目標的行動計劃。很多人並不注重規劃，無論是對個人、團隊，還是對項目。但是，沒有規劃實際上我們是沒有辦法結果導向地去工作的，也沒有辦法去衡量我們做的東西是否符合我們的預期，因為根本就沒有預期。

很常見的情況就是，一些有想法的同學，可能會有時能想到一些不錯的 idea，然後想讓公司給予他機會去做，但大部分同學會出現這麼一個問題就是：隻把焦點關注在技術上怎麼去實現它，沒有一個清晰的規劃，目標可能也隻是最多說解決了一個什麼樣的問題。這樣很多時候會做不出好的成績，因為沒有做規劃。

那怎麼做規劃呢？

首先，我們在做規劃的時候，要明確一個前提，就是我們是要圍繞著業務去做的，要帶著對業務的理解去做，我們不能脫離了業務。比如說你們公司的業務隻有客戶端，結果你提出了一個解決 PC 端性能問題的方案，那肯定是不能爭取到資源去做的。

那麼在結合業務的前提下，我們第一步首先是確定我們的目標收益，比如說我們解決了一個什麼問題，它能給我們在哪個環節提高百分之多少的效率。

然後第二步，才是我們最容易關注到的具體的實現這個目標的設計方案，這個設計方案其實簡單來說就是技術怎麼去實現。

那麼第三步就是落地路徑，落地路徑就是我們如何去實施這個設計方案的一個計劃，比如說我們這個目標要花 3 個月去達成，那麼我們每個月要或者每個星期，要交付什麼樣的東西。這個有些人會把它稱為裏程碑。在設定裏程碑時，有一個比較重要的一點，就是優先級的決定。優先級要思考和論證，明確了優先級，然後去設定裏程碑。另外還有一點，就是我們要設定在什麼情況下出現什麼程度問題了，咱們要止損。

第四步就是衡量的標準，我們要製定一些可量化的客觀的標準，使得我們要吧在交付的時候，有一個標準可以去衡量我們的收益，看是否符合我們最初設定的目標。

要注意的是，衡量標準是在做規劃時就要做好的，很多人往往是在結束時才去衡量，這其實是本末倒置的。

做複盤

「衡量」這個事情其實就是複盤。

相對做規劃是向前看，那麼複盤我們可以說是向後看，它指的是我們從過去的經驗和實際工作中進行學習，幫助大家有效地總結經驗，提升能力的方式。比起不做規劃的人，不做複盤的人甚至會很多。很多人隻盯著之後我們要怎麼做，但是沒有回過頭來，回顧一下我們之前做的東西是怎樣的，這樣我們就沒有辦法知道我們其實做得怎麼樣。

那我們怎麼做複盤呢？

做複盤首先，我們要回顧一下我們最初設定的目標；然後，我們要來評估我們做完之後所得到的結果；第三步，我們要分析一下目標和結果之間的差異；第四步的話，就是總結歸納一下，我們在複盤的過程中，發現了哪些東西我們做得不夠好的，如果讓我們再做一次，我們怎麼做才能做得更好的事情；以及，我們在做這件事的過程中，有哪些經驗可以總結下來，之後可以複用到別的地方去的。

那麼在複盤當中，我們有可能會發現這麼一些的問題。

比如說，最嚴重的，我們根本沒有做規劃，沒有目標，又或者目標不清晰，又或者團隊成員之間對目標缺乏共識，甚至我們目標跟計劃是脫節的。這樣的問題，我們就能夠在第一個環節發現得到。那麼這樣我們就能知道在這一個方麵，我們是做得不夠好的，我們得到一個教訓，我們會知道，在下一次我們做項目之前，一定要先做好規劃，要製定清晰的目標，並且確保所有項目成員對目標能夠達成一致，以及我們的設計方案我們的計劃是符合我們目標的。

又比如說，我們可能會在評估結果或者分析差異的這兩個環節裏麵發現，我們最後得到的結果並沒有達到我們預期的效果。那麼我們就要來分析，到底是哪一個環節出了問題，為什麼會出現這樣的問題，我們有什麼辦法比如說優化流程之類的，可以去規避這樣的問題？

再比如說，我們可能會在這個項目中積累了一些經驗，學習了某項技術或者說得到了哪些心得體會等等，那麼我們就可以把它總結下來，我們再看看能不能在別的項目之中，再複用這樣的經驗，從而提高未來我們的團隊的研發效率。

保持技術視野

我們剛剛說到，做規劃是往前看，做複盤是往後看，但光這樣做是一維的，我們還需要往外看，把我們能力模型變成一個二維的，使得我們做規劃和複盤時，能夠更有效地發現 idea 或者問題。那麼這個往外看呢，就是保持視野。

視野是指我們的思想或者知識的領域。但是視野並不是一成不變的，因為世界在不斷地變化，我們不能閉門造車，要擁抱變化，要以此來調整自己發展的方向。比如我們在做規劃的時候，就可以從別人的項目或者分享當中，提取出可以借鑒的地方，然後結合到我們自身的業務上，這樣做出來的規劃才會更好。所以說，保持我們的視野這很關鍵。

那怎麼保持視野呢？

保持視野我們可以劃三個圈，分別是核心關注圈、一般關注圈和掃盲關注圈。這三個圈劃分的邏輯是依照團隊業務、個人興趣和業界熱點來劃分。

核心關注圈，就是我們在團隊的業務當中可能會每天都用到的，或者說自己感興趣的，又或者說在業界非常火的東西，我們要保持高度的關注。我們最好能知道，它的實現原理是什麼，它或者它的生態每天都有哪些的變化。

一般關注圈，就是我們在團隊的業務當中可能不常用到，但以後很有可能會用到的，或者說自己有點感興趣的，又或者說我們能預判業界之後有可能會火的東西，我們要保持一定的關注度，我們要知道它大概是做什麼的，解決了什麼問題，業界怎麼評價它，有多少公司在使用它，它的趨勢是怎樣的。當需要使用的時候，可以以較快的速度和和較低的成本接入。

掃盲關注圈，就是我們可能業務中不會用到，自己也不太感興趣，業界可能也不太火的，我們不需要放太多的精力去關注它，隻需要知道它大概是做什麼的，解決了什麼問題，就足夠了。

總結

那麼最後我們來把今天分享的內容做一個總結，也順便回答一下前麵一位朋友的提問。我們認為，一個高效的前端團隊，會具有三個元素，分別是架構模式、基礎設施和培養體係，這三個元素是不斷地相互影響的。

我們有了標準化和自動化的方法論，得出了架構模式，同時衍生出了相應的基礎設施，而基礎設施同時又在反向地優化我們的架構。

與此同時，我們也有了我們的培養體係，我們可以針對不同級別的工程師進行不同的培養。對於低階的工程師，我們可以對照著我們的架構和基礎設施來有針對性的設計學習路徑或技術全景圖進行培訓；對於高階工程師，我們用工程師進階的方法論，培養他們做規劃、做複盤和保持視野的能力，從而反向地優化我們的架構模式和基礎設施。

QA

想知道前端團隊的效率如何衡量？一個成熟高效的前端團隊有哪些元素？

這是一個很好的問題，那麼對於後麵的關於「一個成熟高效的前端團隊有哪些元素」這個問題，在總結的時候我們已經聊過了，這裏就不再贅述了。我們現在來聊一下前麵這個「如何衡量前端團隊的效率」這個問題。

效率這個事情，其實是看不見摸不著，但又是客觀上實實在在存在的。那麼概括性地來說的話，就是在固定的周期內能夠完成任務量的規模。我們衡量效率可以用這麼幾個方法。一個是，對於相似的事情，我們可以衡量所消耗的成本的多少來進行衡量；又或者反過來，在相同的成本下，我們可以做多少事情。還有另外一個方向，就是假設我們要做一件事情，有多少東西是重新從零開發的，之前的積累（包括經驗和基礎設施），有多少可以複用？做同樣的事情，我們可以做得快多少，工具、熟練程度。同樣複雜度的需求，能少用多少人去實施。

想了解隻有5個人內的前端團隊怎麼樣的技術體係開發才最有效率？

這個也是一個不錯的問題。

隻有 5 個人的這種級別的團隊，和我們上百個人的團隊，其實是不同的，最大的區別在於，我們可以產生規模效應，我們可能花 100 個 pd 去做一個工具，每次為我們節省 50% 的人力，100 個人的團隊可能就做兩次需求就回本了；但是隻有 5 個人的團隊，可能得做 40 次才能回本。所以說小團隊可以借鑒我們的模式，但不能完全一模一樣地去套。可以考慮隻做標準化，不自己造工具做自動化。

但是小團隊其實跟我們有一點是不一樣的，就是小團隊很敏捷。敏捷意味著，你們切換技術棧、換工具其實成本是很低的，你們可以利用這種的敏捷性去快速試錯，去複用業界成熟的方案來提升效率，盡快把事情先做起來。

團隊怎麼保持業務開發和技術提升的平衡？

我其實不認為業務開發和技術提升是兩個矛盾的事情，相反，剛剛我們在聊如何做規劃的時候，我們就提到過，我們在做規劃的一個前提是，我們要圍繞著業務針對業務痛點，優化用戶體驗，最終提高轉化率。

高階工程師的能力之一就是結合業務去思考技術上的方向，所以我會推薦同學針對業務去做技術上的提升。

剛從開發轉到管理，有點不適應，應該如何順答題卡轉型？美團點評前端部門在麵試時會主要考察哪些方麵的能力？麵試流程是怎樣的？

從開發轉到管理，是個人貢獻者到團隊貢獻者的一個轉變，兩者的本質區別是：技術是自己直接去拿結果，管理是通過別人來拿結果。一開始的時候你會覺得很多事情通過別人來拿結果可能還不如自己來拿得快，但是你要適應這種轉變，因為隨著規模的擴大，隨著你的輔導對別人的幫助，你的團隊會逐漸產生規模效應。作為管理者，應該做的更多是更深入的規劃，以及更深入複盤，無論是對自己還是對團隊。

我們麵試主要考察的能力：學習能力、解決問題能力、專業能力、已經經驗、後續成長的潛力……

麵試流程：兩輪技術麵、一輪綜合麵，上麵要考察的能力基本可以從這三輪裏體現出來。

關於本文

作者：美團@葉俊星

最後更新：2017-10-08 03:52:33

  上一篇： 美團外賣小哥一句惹禍上身，被數名城管圍毆！

  下一篇： 為安全送餐，美團推外賣考試，考不過外賣小哥就不能送餐了