【轉】解密餓了麼大前端團隊

   

    最近，"大前端"這個詞被頻繁說起，不少團隊也在從新思考"大前端團隊"和"移動團隊+前端團隊"這兩種模式的優劣。而在你們還在熱火朝天地討論概念的時候，餓了麼大前端團隊已經茁壯成長，有了不少先人一步的實踐了。InfoQ 特別邀請了餓了麼大前端部門負責人林建鋒，請他結合餓了麼大前端團隊的實踐，向你們分享如何落地和管理一個大前端團隊。
    平時你們會叫我小魚或 Sofish，尷尬的是隻有屈指可數的同行知道我真名叫林建鋒。曾經，爲了逃離數學，大學我選了法學這個專業；而畢業前，又爲了逃離職業性的"辯論"選擇了不用說太多話的前端開發，至此踏上了程序員的不歸路。
    這段程序員的不歸路從實習開始，到遠赴杭州支付寶，然後以第一個前端工程師的身份百姓網，再以後選擇創業，最後加入餓了麼並定居上海。目前做爲餓了麼大前端部門負責人，我和一羣小夥伴在努力把餓了麼變得更好，順路立志成爲業界頂尖團隊。
    1、餓了麼大前端團隊的定位
    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。這些與部門所建立的文化息息相關，且如你可能猜到的，大多合做都是一旦有人提出，即自發組隊。
    2、餓了麼大前端團隊如何看待和落地新技術
    咱們是如何看待新技術的？在面試前端 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 的實驗，能夠想象在不久的未來，線上應用將會大面應用。這就是咱們的選型和落地模式。
    3、餓了麼大前端團隊的特點：散養
    特點？若是隻用兩個字來回答就是 —— 散養。但僅僅這樣描述你們會一臉問號。外部對咱們的評價是："新技術跟進好快啊"、"怎麼又又又出去玩了"、"下班很早"、"好多大牛啊"、"開源的東西得到好多星星啊"，諸如此類，但這不是咱們要特意我呈現的，只是一種表像，或者說是一種副產品。
    一個團隊的風格與創始人有很大的關係，好比喜歡愉懶的我會更多考慮自動化；又若有潔癖因此會有代碼規劃和 Code Review；還有你們看到的愛玩，因此會常常有團建、下午茶這樣的文化；但另外一方面，我並不想讓團隊僅僅是和我同樣有你們喜歡的，同時充滿缺點，而但願是不斷嘗試的，兼容幷包的，讓每一個人的閃光點都成爲集體中有特點標誌的。因此我有本身的一套，就是前端所說的"散養"式管理，提及來可能會很大，重點說幾點：
        招聘最好的人。最好的人不是業界裏的全部明星，更重要的是能從某方面給帶隊帶來提高的人。這些人一般自驅能力強，只要有一個方向就能推進事件的發生和發展。加入的人會被要求不要以學習姿態加入這個團隊，而是以加入會讓這個團隊會讓其變得更好爲姿態，成長就會成爲副產品。
        鼓勵創造結果而不是追求上班時間。若是咱們的目標是頁面加載時間不要超過 800ms，那麼目標就是 800ms 而不是上 12 個小時的班。
        營造環境。咱們有最好的人，咱們追求結果而不是追求上班時間，咱們鼓勵主動和主人公意識，咱們創新以打破規則 ，咱們聲明全部人爲本身而生爲用戶工做而非老闆，咱們會包個酒包或找個海島玩到天亮。有不少東西是要刻意去營造的，創新土壤，主動的意識，熱愛生活的文化，鼓勵什麼就會彙集/培養一羣什麼樣的人。
    由於這樣的管理方式，一般大部分事情都會被內部很好地解決，而我也獲得更多的時間去思考如何作和決定作什麼；團隊也由於成員不斷成長閃耀不一樣的光芒而變得更好。若是以官話來講，就是咱們要發現一種"可持續發展"的模式。這種模式目前運行的不錯，不管是業務上的，仍是團隊文化自己，抑或是加入成員的成長，都是讓人高興的。但，更好的方式仍在探索，若是說只分享一個點的話，那就是千萬別用"管"的方式，而是"理"順，就會瓜熟蒂落。
    至因而不是盲目追求新技術。上面咱們已經談過技術選型的要求，最最重要的也是最最根本的問題"是否進升餓了麼運行的效率或者團隊開發的效率？"，我相信若是你們能回答好這個問題，就解決了"盲目"追求的問題。
    最後說一句，不管是管理上、技術上、生活上，預留必定的空間和自由度，必定會帶來驚喜。具體就不解釋了，你們自行理解，或許某天咱們遇到能夠用這個話題開場，就開聊起來了。
    4、大前端模式的利弊
    "大前端"模式的特色前面已有說起，便是對前端自己的一種能力範圍延伸。移動開發團隊，我這裏指包含移動網頁、Native-Like、Native App 這樣的團隊，如攜程；純大前端的團隊如美團和餓了麼北京研發中心，只要是客戶端的不管是網頁仍是 App 都在單一個團隊；餓了麼不只有大前端，還有各 BU 的 Native App 團隊，甚至還有專一於移動基礎框架的公共的移動技術團隊。
    不一樣的分工模式，其利弊一般與公司狀態、團隊自己所創造的價格有很大的關聯；雖然你們都是"離用戶最近的工程師"，但沒有公式可抄。
    就拿餓了麼大前端來講，最開始是由於業務的快速發展，除了 C 端部門，其餘新成立的部門前端工程師極度緊缺，爲了資源的高效配置，才成立了大前端這個部門。這是當時公司業務的狀態。
    創始人和 CTO 曾問我："你以爲若是今天合了，幾時會分？"當時，個人想法是，若是一個業務前端團隊發展到 10 人左右，在負責好自己的業務外，能創建且不斷升級本身的技術基礎設施又具有有本身的文化，是一個分的時機。時至兩年後的今日，我已再也不是這樣的想法，而且新成立的 BU 更願意把人放到大前端。
    這是爲何呢？咱們從如下幾點分析：
        若是一個大團隊，並不能提便利的基礎設施，不能建立自由且充滿可能的文化，不能持續提高本身並幫助成員提高其自身水平。也就是你們常常談到的技術追求、歸屬感、成就感。那麼，打散到業務組可能更靈活。因此前端業務團隊的分與合歸根到底在於 —— 大團隊是否創造比小團隊更高的價值。
        大多數人高估了"前端+後端+產品"坐在一塊兒的效果，認爲這樣就能完美解決問題。不少時候，對於程序員來講更少的打擾，更多的思考（好比坐內部電梯去找某我的太慢了，就會開始思考是否是有必要去找某我的）事後的溝通，是更高效的溝通。
        劃分框架、機動與業務團隊，一方面基礎設施共享（框架工具）有更多重用，人員調度能夠省很多資源（小團隊需求少的團隊能夠合併支持）且又有專一於業務的團隊，彷佛是最前很是不錯的劃分方式，而在 10 我的的團隊中是很難作到的。
    由此，咱們能夠看出，一方面是業務影響，另外一方面也依賴團隊自己產生的價值，今天咱們要分仍是合，其利弊計算出如今決定作出以後，帶領團隊的人可否利用"合"的優點去產生出更大的價值。這個問題的答案就是利與弊的答案。
    5、業界大前端團隊的現狀
    咱們團隊每一年都會以我的或者團隊名義邀請多位前端業界大牛來內部交流，也會組織內、外部交流會，這一般是幾個電話和微信就搞定的事，整體交流仍是比較多的。即便沒有專門的會議，也會偶爾相互統統氣。
    我沒有具體統計過業界現狀，但從我這邊交流過的團隊來講，如今不少團隊都是大前端方向，或向這個方向發展的比較多。有少部分像攜程、騰訊這種體量自己就很大職能劃分也比較明確的公司，作的事多是"大前端"但分開還是比較偏向於 JS+HTML+CSS 這樣的純前端模式。
    這裏也指望讀者所在的團隊，若有新的實踐和想法咱們能夠偶爾探討。
    6、如何落地一個大前端團隊？
    前文也有提到，要不要組建大前端團隊，一方面是看業務是否有需求，另外一方面是看合可否比分開帶來更大的價值。
    除非人極少，一般來講業務大多數狀況都會隨公司的發展變得越分越開，而價值則主要是關於人和文化。目標不是爲了合而合，或者追隨業界模式，而應該着眼因而否優化了公司的人才架構從而優化業務。
    若是必定要從具體實施點上來講，這裏說兩點：
        1.框架團隊和業務團隊應該同時設立，而且框架與業務不能相互脫離，具體能夠參考餓了麼大前端的模式相互滲透；
        2.在大職能團隊下，儘量以業務劃分團隊，不要以職能劃分團隊；反之亦然。