006_餓了麼大前端總監sofish幫你理清前端工程師及大前端團隊的成長問題！

做者｜Sofish編輯｜小智 & 尾尾本文是前端之巔向 sofish 的約稿《什麼樣的人能夠稱爲架構師？》、採訪《 餓了麼大前端團隊到底是如何落地和管理的?》以及 sofish 作客大咖說直播節目的總結和整理，但願能幫助各位澱粉更清晰地理解 sofish 的觀點。獲取大咖說視頻下載連接，請關注前端之巔並回復「魚老闆」，查看餓了麼大前端更多實踐請回復「餓了麼」。視頻回顧

 

程序員成長之：跨界、困惑與架構師1. 如何看待「大跨度入行編程」——跨界程序員？

從個人角度來講，角色的變換，是一個從興趣到職業的過程。興趣可能持續一段時間就再也不感受興趣了，就放棄了，但職業不同，是擔起的擔子，是對一羣人包括本身的一種責任，有些事不喜歡不只得作，還要作的漂亮。

從法學院出來當程序員其實並無想象中那麼難 。在學校那段時間，晚上常常一寫代碼就忘記時間，看到外面天亮了才睡覺。從不知道如何壓縮 PNG 到解決編碼上的問題。那時候彷佛不須要技巧，一切都是新的，每一個點都是新的，憑着一股單純的熱愛去學習，通宵所感覺到的不是疲憊反卻是一種享受。但工做了，要作好卻並不像入門那麼簡單。一方面是興趣消退，一方面是工做並不能像興趣同樣只作本身喜歡的事，也不能隨意創做，須要按照畫好的 UI 和預約的 UX 來作。因此開始須要一些技巧，或者說一些工做的信條。

工做信條方面。到如今還印象很深入的是，剛工做那會對於任務的第一感覺是「這個網站究竟要作到幾時纔會停下來?」，一切都彷佛沒有終點，人也在工做中變行焦慮起來。這是很難受的一件事。萬幸的是，多方的影響，從完成一件任務的心態慢慢變成如何打磨一個拿的出手做品。這也是如今一直在實踐的一個技巧：一方面要求本身不僅是簡單地去完成一個任務；另外一方面是不要只跟同事作比較，寫文章、開源代碼、出做品接受更多人的挑戰。

年輕的時候一直有一個疑問沒有解開：人與人之間能力是否真的相差十倍甚至百倍千倍？由於武俠小說或者電影裏的英雄一般能以一敵十，而現世生活中人與人之間積累的財富更是有巨大的差異。後來慢慢解開，正常狀況也是，社會資源的流向老是傾向那些準備多一點點，優秀多一點點的人。好比學習成績好會加分，加分會考上更好的學校，好學校會獲得更好的教學環境和更優秀的同伴，諸如此類。

工做也同樣，作的多承擔更多責任，承擔更多責任得到更多回報。除了工做三年積累二十萬拿着爸媽給的六百萬全款買了上海中環內的房子這類非正常的方式外，能者多勞、多勞多得這種套路一直沒有變過。

從學習方法來講。入門一個新領域都會挑選一本比較系統的書來看，讀懂後開始動手作一個相關的項目。好比 CSS 看《精通 CSS》，JS 我會推薦《Pro JavaScript》，設計有一本叫《寫給你們看的設計書》是一本不錯的入門書，後來學 SQL、PHP、Go 同樣，剛轉到管理崗那會也是看了好幾本管理書邊學邊用。彷佛總能獲得不錯的結果。

關於如何從非科班生變成技術總監。你們的方法都不一樣，但有一點必定是相同的 —— 不設限。若是你們只見解學方面的書，就不會寫代碼，天然不會成爲程序員更別說技術總監。前端能夠學點設計，天然也能夠學後端，甚至操做機器。去年得了公司的管理獎，算是對本身管理上的階段性確定。所以上半年給本身定了個目標是看懂財報，學習從會計的角度是如何看公司的。

2. 如何看待「編程終極目標」——架構師？

我曾問過不少自稱熱愛代碼的程序員的發展規劃，大多都回答說指望成爲一名架構師。而在招聘一方，有的團隊會過濾掉屢次提起架構一詞而一點不提具體內容的簡歷。可見，雖然在大多數程序員眼裏，架構師是神聖的，但又不得不認可事實是：「架構」和「架構師」是最常被濫用的。那些寫能 PPT 而不能寫代碼的人，只作和事佬而不考慮軟件快、穩、便捷的人，都稱不上作「架構」更別提「架構師」。

那麼什麼樣的人能夠稱爲「架構師」？

據稱架構一詞源於建築行業，架構師這個職位，無論是前端仍是後端，職責是相同的。而用規劃一次房屋的裝修來描述架構師這個職位的職責是很是合適的。

創建一套 Web API 就像在定裝修風格。要選擇注重重 CRUD 的 RESTFul 式，仍是請求自定義性更強的 GraphQL 式，又或者是簡單的 JSON-RPC 式，這就像裝修風格是選要簡潔的日式、粗獷的美式仍是奢華的歐式。定方向和選型這件事無處不在，架構師必須根據實際需求，作各類決策，爲後面各部分總體結合打好基礎。

燈光、牆面、傢俱等各個部分都須要根據風格精心設計、執行和不斷修正，纔可能達到原定目標，架構也同樣。拿光線控制來講，施工人員可能會忽略你注重的一些細節：暖色的書房氛圍；明亮且能切到影院模式的客廳；裝在合適位置纔不會刺眼的背景燈。在每一個環節的執行上，架構師既要設計，又要保證對每一個角色充分理解，必要時不排除動手編寫重要環節的功能，而在經驗或考慮不足的點上一旦出現問題就必須迅速調整。空有一個好的設計而沒有好的執行，是很是讓人可惜的。

值得一提的是，選用最好的衛浴用品、最貴的過濾器並非得到最佳洗浴室體驗的關鍵點。一樣，軟件架構並非說把每一個部分作到最好再拼湊起來就能達到佳效果。最好洗浴室體驗的關鍵點在於折中和妥協。例如，在水壓不是特別高的狀況下，把過濾器安裝在總閘雖然能讓用水達到最健康的狀態，但會致使淋浴的水壓不夠，進而使體驗大打折扣。把過濾器安裝在廚房出水口多是最佳的平衡，既保證水壓又保證了用水的健康。分紅多個部分是解耦，而協做的平衡是內聚。低耦合、高內聚是架構師處理軟件各部分協做的終極目標。

裝修有不少細節，例如，若不喜歡晾衣服且生活在有「黃梅天」的上海，可選洗烘一體機；房子面積不大，可選擴展型傢俱；對通風質量要求比較高，可安裝新風系統。軟件架構也須要考慮不少細節，例如客戶需求、實際環境、技術可用黑科技之類、安全、重用、擴展等。而這些細節方面的考慮，並非一個剛入門的新人能作到的。

總的來講，稱得上架構師的人，必須是具有豐富系統設計經驗且能保證設計執行的設計師和決策者；必須參與設計、開發執行和測試但又不侷限於一個角色。也許架構師並不必定全是這樣，這僅表明我的見解和指望。

3. 如何解答程序員的成長困惑？跳槽如何選擇？

跳槽這件事我並無什麼話權，祼辭和看緣分彷佛是我一直的方法，固然談薪資也同樣，因此不止一次被老婆說根本不懂得如何去賺錢。不過從選擇團隊上，我有一個不錯的建議，也是我本身選擇的底線，兩種團隊：一是選擇喜歡的一個產品；一是選擇一個有趣的團隊。

選擇一個喜歡的產品。若是你喜歡餓了麼讓全世界都足不出戶就能夠享受各類美食，那麼有什麼理由不加入？工做就是人生追求這件事，簡直夢寐以求。喜歡一個產品老是很直接的，因此選擇起來很是簡單。

爲何要選擇一個有趣的團隊？一個被業務纏身的團隊是沒法有趣的，沒時間；一個沒有水平的團隊是沒法有趣的，爛事一堆都焦頭爛額了，哪來有趣？有趣的團隊必定是好玩的，且熱愛生活的，這樣的團隊一般不只能夠學到新的酷的，還會獲得一羣有趣的朋友。但如何判斷一個團隊是否有趣呢？看他們的做品，是否是老是爲了生活更簡單，好比喜歡自動化，喜歡抽象，交互簡單且有效等等；或者看他們是否有很特別的方式在玩，好比找個海島、包個酒吧之類，或者去深山裏玩狼人殺。

不管是否有這樣的團隊，我以爲有一點比選擇更重要的是，成爲一個某個產品或團隊由於有你而變得更好的人；若是沒有這樣的產品或者團隊，那麼個人方式是 —— 創造一個。

技術和管理如何互轉？

關於技術和管理如何互轉上，不少人以爲因人而異，照本身的喜歡的來選就能夠了。作了這麼久的技術，轉到管理崗於我，就像從法學院畢竟轉身成爲程序員同樣，是一個新的挑戰，當時義無反顧接受。若是你也同樣，碰到一些兩個單選均可以的狀況，照個人見解是，既然生命只有一次爲什麼一直重複作一樣的事。事實上，每次選擇的結果彷佛都還不錯。

順路分享一個有趣的心路歷程。上上週人在美國 LA，當時第一次在那邊開車，陌生的 JEEP 大切諾基、山路、晚上，而且中間被警察攔下來過一次，不過這些都不重要。重要的是在公路上你們都開的超快，當時我也開的特別快，朋友說剛想睡就被我一個彎就愰醒了。過後你們都以爲我開車真的有點太嚇人。而當時內心卻只有一句話 —— 若是一切都在掌控之中，說明一切跑的並不足夠快。若是生活老是在掌握之中，說明咱們跑的並不足夠快，甚至只是原地踏步。

其餘就不說了，分享一個初作管理的心得和一個成就優秀團隊的重要的策略。

心得。你們均可能摸清了套路，寫代碼你只要作的比預期多一點點，代碼寫的抽象一點點，你們都會開始叫你大神，說你就是那樣棒棒的。因此作管理的時候，碰到別人不會的問題，你一般過會想 —— 「走開，讓我來」。千萬別這樣作！無論你懂或者不懂這句話的真正涵義，千萬別這樣作。而後，你就會開始獲得不少很好的助手。這個就很少解釋了，有些事能夠邊學邊作，越受打擊越強大。

策略。永遠不要靜止地看團隊，特別是在招人上。什麼叫靜態地看待團隊？舉個例子，有多少業務申請多少資源，而後業務永遠都在原地踏步，團隊永遠在只是一個創建時同樣的團隊。個人策略是這樣的，一方面半年前與半年後招聘同一級的人必定要比原來的要求更高，且重點挑選團隊缺乏的人才；一方面看半年到一年後但願變成一個什麼樣的團隊，而去作相應的 5% 左右的人才儲備。看似浪費資源，但長遠來看，相比由於招不到人支持不了業務的時候纔是真正的浪費。

統觀大前端之概念及團隊落地4. 如何看待大前端的概念？

大前端一般是指全部客戶端，由於會有 Native App 和 Web 兩個前端；另外還泛指不只僅是負責靜態內容，而是向後端擴展負責更多的內容，好比除 Model/DB 層之外都稱爲前端。簡單來講就是前端及接受前端的層。方面其實不是很重要，若是喜歡跟 UI 打交道，那麼選擇大前端就沒錯了。

在參加大咖說的直播過程當中，有觀衆問到一個問題 —— 前端會消亡嗎？從社會分工的角度來講，彷佛目前仍是比較穩定的職位。但現實世界變化特別快。之前咱們看父母輩均可以在一家公司工做上 二、30 年，而今一家公司是否能存活這麼久仍是一個問題，幾乎能夠說，這個世界上惟一不變的就是變化，並且愈來愈快。因此不管選擇什麼方向，一方面盡力作到最好；另外一方面不要給本身設限，去接受更多挑戰以提高本身；這樣多是比選擇一個方向要更靠譜的方法。

5. 餓了麼大前端團隊的定位是什麼？（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。這些與部門所建立的文化息息相關，且如你可能猜到的，大多合做都是一旦有人提出，即自發組隊。

6. 餓了麼大前端如何看待和落地新技術？

咱們是如何看待新技術的？在面試前端 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 的實驗，能夠想象在不久的未來，線上應用將會大面應用。這就是咱們的選型和落地模式。

7. 餓了麼大前端團隊的特點是什麼？

特點？若是隻用兩個字來回答就是 —— 散養。但僅僅這樣描述你們會一臉問號。外部對咱們的評價是：「新技術跟進好快啊」、「怎麼又又又出去玩了」、「下班很早」、「好多大牛啊」、「開源的東西得到好多星星啊」，諸如此類，但這不是咱們要特意我呈現的，只是一種表像，或者說是一種副產品。

一個團隊的風格與創始人有很大的關係，好比喜歡愉懶的我會更多考慮自動化；又若有潔癖因此會有代碼規劃和 Code Review；還有你們看到的愛玩，因此會常常有團建、下午茶這樣的文化；但另外一方面，我並不想讓團隊僅僅是和我同樣有你們喜歡的，同時充滿缺點，而但願是不斷嘗試的，兼容幷包的，讓每一個人的閃光點都成爲集體中有特點標誌的。因此我有本身的一套，就是前端所說的「散養」式管理，提及來可能會很大，重點說幾點：

1. 招聘最好的人。最好的人不是業界裏的全部明星，更重要的是 能從某方面給帶隊帶來提高的人。這些人一般自驅能力強，只要有一個方向就能推進事件的發生和發展。加入的人會被要求不要以學習姿態加入這個團隊，而是以加入會讓這個團隊會讓其變得更好爲姿態，成長就會成爲副產品。

2. 鼓勵創造結果而不是追求上班時間。若是咱們的目標是頁面加載時間不要超過 800ms，那麼目標就是 800ms 而不是上 12 個小時的班。

3. 營造環境。咱們有最好的人，咱們追求結果而不是追求上班時間，咱們鼓勵主動和主人公意識，咱們創新以打破規則 ，咱們聲明全部人爲本身而生爲用戶工做而非老闆，咱們會包個酒包或找個海島玩到天亮。有不少東西是要刻意去營造的，創新土壤，主動的意識，熱愛生活的文化，鼓勵什麼就會彙集 / 培養一羣什麼樣的人。

由於這樣的管理方式，一般大部分事情都會被內部很好地解決，而我也獲得更多的時間去思考如何作和決定作什麼；團隊也由於成員不斷成長閃耀不一樣的光芒而變得更好。若是以官話來講，就是咱們要發現一種「可持續發展」的模式。這種模式目前運行的不錯，不管是業務上的，仍是團隊文化自己，抑或是加入成員的成長，都是讓人高興的。但，更好的方式仍在探索，若是說只分享一個點的話，那就是千萬別用「管」的方式，而是「理」順，就會瓜熟蒂落。

至因而不是盲目追求新技術。上面咱們已經談過技術選型的要求，最最重要的也是最最根本的問題「是否進升餓了麼運行的效率或者團隊開發的效率？」，我相信若是你們能回答好這個問題，就解決了「盲目」追求的問題。

最後說一句，不管是管理上、技術上、生活上，預留必定的空間和自由度，必定會帶來驚喜。具體就不解釋了，你們自行理解，或許某天咱們遇到能夠用這個話題開場，就開聊起來了。

8. 大前端模式的利弊有哪些？

「大前端」模式的特色前面已有說起，便是 對前端自己的一種能力範圍延伸。移動開發團隊，我這裏指包含移動網頁、Native-Like、Native App 這樣的團隊，如攜程；純大前端的團隊如美團和餓了麼北京研發中心，只要是客戶端的不管是網頁仍是 App 都在單一個團隊；餓了麼不只有大前端，還有各 BU 的 Native App 團隊，甚至還有專一於移動基礎框架的公共的移動技術團隊。

不一樣的分工模式，其利弊一般與公司狀態、團隊自己所創造的價格有很大的關聯；雖然你們都是「離用戶最近的工程師」，但沒有公式可抄。

就拿餓了麼大前端來講，最開始是由於業務的快速發展，除了 C 端部門，其餘新成立的部門前端工程師極度緊缺，爲了資源的高效配置，才成立了大前端這個部門。這是當時公司業務的狀態。

創始人和 CTO 曾問我：「你以爲若是今天合了，幾時會分？」當時，個人想法是，若是 一個業務前端團隊發展到 10 人左右，在負責好自己的業務外，能創建且不斷升級本身的技術基礎設施又具有有本身的文化，是一個分的時機。時至兩年後的 今日，我已再也不是這樣的想法，而且新成立的 BU 更願意把人放到大前端。

這是爲何呢？咱們從如下幾點分析：

1. 若是一個大團隊，並不能提便利的基礎設施，不能建立自由且充滿可能的文化，不能持續提高本身並幫助成員提高其自身水平。也就是你們常常談到的技術追求、歸屬感、成就感。那麼，打散到業務組可能更靈活。因此 前端業務團隊的分與合歸根到底在於 —— 大團隊是否創造比小團隊更高的價值。

2. 大多數人高估了「前端 + 後端 + 產品」坐在一塊兒的效果，認爲這樣就能完美解決問題。不少時候，對於程序員來講更少的打擾，更多的思考（好比坐內部電梯去找某我的太慢了，就會開始思考是否是有必要去找某我的）事後的溝通，是更高效的溝通。

3. 劃分框架、機動與業務團隊，一方面基礎設施共享（框架 / 工具）有更多重用，人員調度能夠省很多資源（小團隊 _ 需求少的團隊能夠合併支持）且又有專一於業務的團隊，彷佛是最前很是不錯的劃分方式，而在 10 我的的團隊中是很難作到的。

由此，咱們能夠看出，一方面是業務影響，另外一方面也依賴團隊自己產生的價值，今天咱們要分仍是合，其利弊計算出如今決定作出以後，帶領團隊的人可否利用「合」的優點去產生出更大的價值。這個問題的答案就是利與弊的答案。

9. 如何看業界大前端團隊的現狀？

咱們團隊每一年都會以我的或者團隊名義邀請多位前端業界大牛來內部交流，也會組織內、外部交流會，這一般是幾個電話和微信就搞定的事，整體交流仍是比較多的。即便沒有專門的會議，也會偶爾相互統統氣。

我沒有具體統計過業界現狀，但從我這邊交流過的團隊來講，如今不少團隊都是大前端方向，或向這個方向發展的比較多。有少部分像攜程、騰訊這種體量自己就很大職能劃分也比較明確的公司，作的事多是「大前端」但分開還是比較偏向於 JS+HTML+CSS 這樣的純前端模式。

這裏也指望讀者所在的團隊，若有新的實踐和想法咱們能夠偶爾探討。

10. 要不要組建大前端團隊？

前文也有提到，要不要組建大前端團隊，一方面是看業務是否有需求，另外一方面是看合可否比分開帶來更大的價值。

除非人極少，一般來講業務大多數狀況都會隨公司的發展變得越分越開，而價值則主要是關於人和文化。目標不是爲了合而合，或者追隨業界模式，而應該着眼因而否優化了公司的人才架構從而優化業務。

若是必定要從具體實施點上來講，這裏說兩點：

• 框架團隊和業務團隊應該同時設立，而且框架與業務不能相互脫離，具體能夠參考餓了麼大前端的模式 —— 相互滲透；

• 在大職能團隊下，儘量以業務劃分團隊，不要以職能劃分團隊；反之亦然。

Reference:http://www.infoq.com/cn/news/2017/03/Hungry-front-team-decryption