最近，"大前端"這個詞被頻繁提及，很多團隊也在重新思考"大前端團隊"和"移動團隊+前端團隊"這兩種模式的優劣。而在大家還在熱火朝天地討論概念的時候，餓了麽大前端團隊已經茁壯成長，有了很多先人一步的實踐了。InfoQ 特別邀請了餓了麽大前端部門負責人林建鋒，請他結合餓了麽大前端團隊的實踐，向大家分享如 ...
最近，"大前端"這個詞被頻繁提及，很多團隊也在重新思考"大前端團隊"和"移動團隊+前端團隊"這兩種模式的優劣。而在大家還在熱火朝天地討論概念的時候，餓了麽大前端團隊已經茁壯成長，有了很多先人一步的實踐了。InfoQ 特別邀請了餓了麽大前端部門負責人林建鋒，請他結合餓了麽大前端團隊的實踐，向大家分享如何落地和管理一個大前端團隊。
平時大家會叫我小魚或 Sofish，尷尬的是只有屈指可數的同行知道我真名叫林建鋒。曾經，為了逃離數學，大學我選了法學這個專業；而畢業前，又為了逃離職業性的"辯論"選擇了不用說太多話的前端開發，至此踏上了程式員的不歸路。
這段程式員的不歸路從實習開始，到遠赴杭州支付寶，而後以第一個前端工程師的身份百姓網，再之後選擇創業，最後加入餓了麽並定居上海。目前作為餓了麽大前端部門負責人，我和一群小伙伴在努力把餓了麽變得更好，順路立志成為業界頂尖團隊。
一、餓了麽大前端團隊的定位
1.為什麼叫"大前端"團隊
大前端這個詞最早是因為在阿裡內部有很多前端開發人員既寫前端又寫 Java 的 Velocity 模板而得，而我們部門成為之初所承擔的內容不僅僅是前端，還包含 CDN 和 Nginx 層，所以取名"大前端"。時至今日，大家所說的大前端已經包含了前端、Node、Native-Like (Hybrid / Weex / RN)，甚至包括 Native App 開發。
2.我所理解的"大前端"
在我看來，"大前端"是一種變化形態多過於固定的職責範圍，是"前端"職責範圍的延伸，是對這個社會分工因為能力範圍和因此所達到效率提升的一種進化形態。給大家分享個小道消息：CTO 曾多次開玩笑說 —— 你們負責的已經不僅僅是前端，要不就改名"大全棧"吧。這部門的名字很霸氣但同時也太高調，所有並沒有接受 BOSS 的提議，而是繼續沿用"大前端"這個部門名。
3.餓了麽大前端團隊的職責
如上面所說的，除了純 iOS / Android App 的開發，其他都是我們團隊職責所在，同時我們還負責公司 HTTP API 層，有一些自己運維的系統。
從分工來說來，目前我們有架構與機動組負責框架、規範、工具的生產；Node 研發團隊負責公司 Node 業務的基礎設施和業務支撐；多個業務前端團隊支持不同的 BU 前端。這裡值得一提的是，架構與機動組會對每個業務團隊至少派出一名架構師長期、深入地瞭解業務團隊所遇到的問題並反饋到架構團隊，併在解決方案提出後協助推動。
在具體職能分工之外，各團隊也有以項目而組織起來的虛擬團隊，比如由我們部門負責的"游戲中心系統"就由 Node 研發團隊和架構與機場組中的成員組成；又如小程式團隊；亦如發起一次由"93後"獨立組織的招聘；專欄編輯團隊、官微小分隊、對內對外分享會小分隊，等等。除了大家看到的開源產品，內部的所有項目都是"內部開源"，特別鼓勵大家提 Pull Request 和相互 Code Review。這些與部門所創建的文化息息相關，且如你可能猜到的，大多合作都是一旦有人提出，即自發組隊。
二、餓了麽大前端團隊如何看待和落地新技術
我們是如何看待新技術的？在面試前端 Leader 候選人的時候，我通常會問一個問題：你如何看待技術債，有沒有辦法可以避免？幾乎任何程式員都討厭還技術債，所以才會有那句"挖坑一時爽，填坑火葬場"。因為痛苦才會非常值得我們去思考和解決。技術債從某種程式上代表著過時的技術，而新技術也將在未來某個時刻變成新的"技術債"。餓了麽大前端是如何回答這個問題的？就是我們對新技術的看法。
我 2014 年加入餓了麽，那會 PC 和 Mobile 都還是後端渲染的模式，使用 Bootstrap 和 jQuery。我進去的第一件事是用 Angular.js 重寫移動網站，並且前/後端分離，提倡後端即服務。在高速發展期利用移動網站支撐了當時 10 倍增長的業務；第二件事是重構 PC 站，把 web2 升級到 web3（Code Name），同樣是前後端分離，到 14 年底 15 年初，基本實現完全分離。重構一方面是提高前端協作的效率，一方面是提升兩部各自的掌握力 —— 只要 API 約定一致，內部封裝可以自己隨時變更（提升）。在此之後，我們的方向一直是比較激進的技術模式 —— 新業務可以用任何框架，大家自由選擇；舊業務只要負責團隊（人）有能力升級，那就鼓勵用最新的。由於後端已經完全分離出去，所以從掌握力大大提升，加上這種受鼓勵的激進技術模式，Angular.js 1.x 這種當年的新技術在日漸變成技術債的今天，也已經幾乎全被重寫成 Vue.js 和 React.js。
當然，也像今天大家能看到的，當大家都還在轉發關於 PWA 文章的時候，我們已經和 Google 合作並把 PWA 上線；開源的項目大多是內部成熟應用的項目，而開源的產品亦讓我們成為 Vue.js World Ranking 最高的團隊；Weex 方面，我們是除阿裡內部團隊外最早上線的大型用戶。這些看起來快速和無止追求新技術的背後，其實並沒有大家想的那麼了不起，僅僅是因為團隊文化本身就鼓勵利用新技術解決問題。
如果一定要拿 Vue.js 來舉例，可能和你想象不一樣的是，不用"落地"，僅僅是因為有人說了一句"WOW，Vue.js 寫起來好簡潔啊，大家要不要一起來試試？"。然後，一個團隊，兩個團隊... 幾乎所有團隊都開始應用，幾乎所有新項目都在用。一位 IBM 的朋友告訴我，他申請在項目試用 Vue.js，上級說在半年後試用，結果半年後又被推翻了。所以你看，在合適的文化土壤里新事物就是一種常態，如果做一個項目用什麼技術還要上級主管確定"能不能做"，那本身就不是一件簡單的事。
我們對於技術選型通常來說要求是 —— 是否提升餓了麽運行的效率或者團隊開發的效率？是否能 hold 住？有沒有人負責到底？符合這樣的條件，就會被推動。當大家都在說 HTTPS 是好東西的時候，我們已經推動全網上線，諸如此類 —— Webp、Https、Vue.js / React.js / Angular.js、Weex、PWA 都是如此。比如大家可能去年就關註到我們在上線 HTTP/2，而今天餓了麽大前端內部已經做過 HTTP/2 Server Push 的實驗，可以想象在不久的將來，線上應用將會大面應用。這就是我們的選型和落地模式。
三、餓了麽大前端團隊的特色：散養
特色？如果只用兩個字來回答就是 —— 散養。但僅僅這樣描述大家會一臉問號。外部對我們的評價是："新技術跟進好快啊"、"怎麼又又又出去玩了"、"下班很早"、"好多大牛啊"、"開源的東西獲得好多星星啊"，諸如此類，但這不是我們要特地我呈現的，只是一種表像，或者說是一種副產品。
一個團隊的風格與創始人有很大的關係，比如喜歡愉懶的我會更多考慮自動化；又如有潔癖所以會有代碼規劃和 Code Review；還有大家看到的愛玩，所以會經常有團建、下午茶這樣的文化；但另一方面，我並不想讓團隊僅僅是和我一樣有大家喜歡的，同時充滿缺點，而希望是不斷嘗試的，相容並包的，讓每個人的閃光點都成為集體中有特色標誌的。所以我有自己的一套，就是前端所說的"散養"式管理，說起來可能會很大，重點說幾點：
招聘最好的人。最好的人不是業界里的所有明星，更重要的是能從某方面給帶隊帶來提升的人。這些人通常自驅能力強，只要有一個方向就能推動事件的發生和發展。加入的人會被要求不要以學習姿態加入這個團隊，而是以加入會讓這個團隊會讓其變得更好為姿態，成長就會成為副產品。
鼓勵創造結果而不是追求上班時間。如果我們的目標是頁面載入時間不要超過 800ms，那麼目標就是 800ms 而不是上 12 個小時的班。
營造環境。我們有最好的人，我們追求結果而不是追求上班時間，我們鼓勵主動和主人公意識，我們創新以打破規則 ，我們聲明所有人為自己而生為用戶工作而非老闆，我們會包個酒包或找個海島玩到天亮。有很多東西是要刻意去營造的，創新土壤，主動的意識，熱愛生活的文化，鼓勵什麼就會聚集/培養一群什麼樣的人。
因為這樣的管理方式，通常大部分事情都會被內部很好地解決，而我也得到更多的時間去思考如何做和決定做什麼；團隊也因為成員不斷成長閃耀不同的光芒而變得更好。如果以官話來說，就是我們要發現一種"可持續發展"的模式。這種模式目前運行的不錯，無論是業務上的，還是團隊文化本身，抑或是加入成員的成長，都是讓人高興的。但，更好的方式仍在探索，如果說只分享一個點的話，那就是千萬別用"管"的方式，而是"理"順，就會順理成章。
至於是不是盲目追求新技術。上面我們已經談過技術選型的要求，最最重要的也是最最根本的問題"是否進升餓了麽運行的效率或者團隊開發的效率？"，我相信如果大家能回答好這個問題，就解決了"盲目"追求的問題。
最後說一句，無論是管理上、技術上、生活上，預留一定的空間和自由度，一定會帶來驚喜。具體就不解釋了，大家自行理解，或許某天我們遇到可以用這個話題開場，就開聊起來了。
四、大前端模式的利弊
"大前端"模式的特點前面已有提及，即是對前端本身的一種能力範圍延伸。移動開發團隊，我這裡指包含移動網頁、Native-Like、Native App 這樣的團隊，如攜程；純大前端的團隊如美團和餓了麽北京研發中心，只要是客戶端的無論是網頁還是 App 都在單一個團隊；餓了麽不僅有大前端，還有各 BU 的 Native App 團隊，甚至還有專註於移動基礎框架的公共的移動技術團隊。
不同的分工模式，其利弊通常與公司狀態、團隊本身所創造的價格有很大的關聯；雖然大家都是"離用戶最近的工程師"，但沒有公式可抄。
就拿餓了麽大前端來說，最開始是因為業務的快速發展，除了 C 端部門，其他新成立的部門前端工程師極度緊缺，為了資源的高效配置，才成立了大前端這個部門。這是當時公司業務的狀態。
創始人和 CTO 曾問我："你覺得如果今天合了，幾時會分？"當時，我的想法是，如果一個業務前端團隊發展到 10 人左右，在負責好本身的業務外，能建立且不斷升級自己的技術基礎設施又具備有自己的文化，是一個分的時機。時至兩年後的今日，我已不再是這樣的想法，並且新成立的 BU 更願意把人放到大前端。
這是為什麼呢？我們從以下幾點分析：
如果一個大團隊，並不能提便利的基礎設施，不能創建自由且充滿可能的文化，不能持續提升自己並幫助成員提升其自身水平。也就是大家經常談到的技術追求、歸屬感、成就感。那麼，打散到業務組可能更靈活。所以前端業務團隊的分與合歸根到底在於 —— 大團隊是否創造比小團隊更高的價值。
大多數人高估了"前端+後端+產品"坐在一起的效果，認為這樣就能完美解決問題。很多時候，對於程式員來說更少的打擾，更多的思考（比如坐內部電梯去找某個人太慢了，就會開始思考是不是有必要去找某個人）過後的溝通，是更高效的溝通。
劃分框架、機動與業務團隊，一方面基礎設施共用（框架工具）有更多重用，人員調度可以省不少資源（小團隊需求少的團隊可以合併支持）且又有專註於業務的團隊，似乎是最前非常不錯的劃分方式，而在 10 個人的團隊中是很難做到的。
由此，我們可以看出，一方面是業務影響，另一方面也依賴團隊本身產生的價值，今天我們要分還是合，其利弊計算出現在決定做出之後，帶領團隊的人能否利用"合"的優勢去產生出更大的價值。這個問題的答案就是利與弊的答案。
五、業界大前端團隊的現狀
我們團隊每年都會以個人或者團隊名義邀請多位前端業界大牛來內部交流，也會組織內、外部交流會，這通常是幾個電話和微信就搞定的事，總體交流還是比較多的。即使沒有專門的會議，也會偶爾相互通通氣。
我沒有具體統計過業界現狀，但從我這邊交流過的團隊來說，現在很多團隊都是大前端方向，或向這個方向發展的比較多。有少部分像攜程、騰訊這種體量本身就很大職能劃分也比較明確的公司，做的事可能是"大前端"但分開仍是比較偏向於 JS+HTML+CSS 這樣的純前端模式。
這裡也期望讀者所在的團隊，如有新的實踐和想法我們可以偶爾探討。
六、如何落地一個大前端團隊？
前文也有提到，要不要組建大前端團隊，一方面是看業務是否有需求，另一方面是看合能否比分開帶來更大的價值。
除非人極少，通常來說業務大多數情況都會隨公司的發展變得越分越開，而價值則主要是關於人和文化。目標不是為了合而合，或者追隨業界模式，而應該著眼於是否優化了公司的人才架構從而優化業務。
如果一定要從具體實施點上來說，這裡說兩點：
1.框架團隊和業務團隊應該同時設立，並且框架與業務不能相互脫離，具體可以參考餓了麽大前端的模式相互滲透；
2.在大職能團隊下，儘可能以業務劃分團隊，不要以職能劃分團隊；反之亦然。
