作者｜Sofish編輯｜小智 & 尾尾本文是前端之巔向 sofish 的約稿《什麽樣的人可以稱為架構師？》、采訪《 餓了麽大前端團隊究竟是如何落地和管理的?》以及 sofish 做客大咖說直播節目的總結和整理，希望能幫助各位澱粉更清晰地理解 sofish 的觀點。獲取大咖說視頻下載鏈接，請關註前端之巔並回復“魚老板”，查看餓了麽大前端更多實踐請回復“餓了麽”。視頻回顧

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

從我的角度來說，角色的變換，是一個從興趣到職業的過程。興趣可能持續一段時間就不再感覺興趣了，就放棄了，但職業不一樣，是擔起的擔子，是對一群人包括自己的一種責任，有些事不喜歡不僅得做，還要做的漂亮。

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

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

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

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

從學習方法來說。入門一個新領域都會挑選一本比較系統的書來看，讀懂後開始動手做一個相關的項目

關於如何從非科班生變成技術總監。大家的方法都不同，但有一點一定是相同的 —— 不設限。如果大家只看法學方面的書，就不會寫代碼，自然不會成為程序員更別說技術總監。前端可以學點設計，自然也可以學後端，甚至操作機器。去年得了公司的管理獎，算是對自己管理上的階段性肯定。因此上半年給自己定了個目標是看懂財報，學習從會計的角度是如何看公司的。

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

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

那麽什麽樣的人可以稱為“架構師”？

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

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

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

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

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

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

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

跳槽這件事我並沒有什麽話權，祼辭和看緣分似乎是我一直的方法，當然談薪資也一樣，所以不止一次被老婆說根本不懂得如何去賺錢。不過從選擇團隊上，我有一個不錯的建議，也是我自己選擇的底線，兩種團隊：一是選擇喜歡的一個產品；一是選擇一個有趣的團隊。

選擇一個喜歡的產品。如果你喜歡餓了麽讓全世界都足不出戶就可以享受各種美食，那麽有什麽理由不加入？工作就是人生追求這件事，簡直求之不得。喜歡一個產品總是很直接的，所以選擇起來非常簡單。

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

無論是否有這樣的團隊，我覺得有一點比選擇更重要的是，成為一個某個產品或團隊因為有你而變得更好的人；如果沒有這樣的產品或者團隊，那麽我的方式是 —— 創造一個。

技術和管理如何互轉？

關於技術和管理如何互轉上，很多人覺得因人而異，照自己的喜歡的來選就可以了。做了這麽久的技術，轉到管理崗於我，就像從法學院畢竟轉身成為程序員一樣，是一個新的挑戰，當時義無反顧接受。如果你也一樣，碰到一些兩個單選都可以的情況，照我的看法是，既然生命只有一次為何一直重復做同樣的事。事實上，每次選擇的結果似乎都還不錯。

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

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

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

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

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

大前端通常是指所有客戶端，因為會有 Native App 和 Web 兩個前端；另外還泛指不僅僅是負責靜態內容，而是向後端擴展負責更多的內容，比如除 Model/DB 層以外都稱為前端。簡單來說就是前端及接受前端的層。方面其實不是很重要，如果喜歡跟 UI 打交道，那麽選擇大前端就沒錯了。

在參加大咖說的直播過程中，有觀眾問到一個問題 —— 前端會消亡嗎？從社會分工的角度來說，似乎目前還是比較穩定的職位。但現實世界變化特別快。以前我們看父母輩都可以在一家公司工作上 2、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

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