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