原創不易，希望能關注下我們，再順手點個贊~~
本文首發於政採雲前端團隊部落格： Winter 在政採雲分享實錄 -《前端團隊的成長》
前言
<FDay>前端技術分享會，是政採雲前端團隊（ZooTeam）的月度分享會。 2019 年的 10 月期，我們有幸邀請到了 Winter（程劭非） ，為我們的前端同學做了一期關於前端團隊成長的主題分享。之前也邀請過其他大牛來政採雲 <FDay> 分享，如阿里雲 IoT 高階技術專家@額臺，宋小菜大前端負責人@Scott 等，可惜當時都沒做現場記錄。Winter 這一期，我們的同學現場做了一下分享記錄，全程 Winter 大大妙語連珠，大家笑聲陣陣，現場速記難免存在細節遺漏，文章部分內容存在簡略，但相信依然能傳遞一些有價值的認知和思考，幫助到列位看官。
什麼是一個好的前端團隊？氛圍好？技術強？機會多？一千個讀者心中有一千個哈姆雷特，相信每個人都有不同的答案。就拿剛畢業的應屆生就業來說，有人想去大廠，因為大廠基礎設施完善，有大牛帶，成長快；也有人想去小公司，因為小公司的基礎設施不完善，就會有很多的機遇，有晉升的空間。本次分享 Winter 從前端團隊的基石、前端團隊的核心因素和前端團隊的亮點三方面來談一談這個話題。
分享嘉賓簡介
Winter（程劭非），先後任職於微軟、盛大、阿里巴巴，阿里時期擔任手機淘寶前端負責人，帶領團隊產出 Weex 等跨平臺的移動端解決方案。極客時間《重學前端》系列課程作者。
前端團隊的需求模型
我們先通過一張模型圖來解讀一個前端團隊中存在的角色以及各個角色之間的聯絡。
這張圖可以從兩個角度看，一是從公司的角度往下看，二是從員工的角度往上看。其中，團隊在模型中出現了兩次，它的地位和重要性顯而易見。
團隊 Leader 是一個很重要的角色，既要應對團隊成員的需求，又要從公司的角度來應對上級的需求。對公司來說，公司給團隊的是一定的資源，這些資源包括薪酬、工位、電腦等等。
團隊給員工的是成長，團隊給隊員的機會是均等的，團隊就像是培育小樹苗的土壤，外部條件都是一樣的，但小樹苗能長多高長多大還是要看個人了。
員工給團隊的是技術和勞動，技術是專業的代名詞，它和勞動不能劃等號，不是任何一個人過來工作兩小時的產出都是一樣的。
團隊給公司的是業務價值，業務價值就和大家年終的績效掛鉤了。
這四個環節缺一不可，都齊活了才是一個完整的前端團隊需求模型。
前端團隊的基石——質量和效率
一個技術團隊安身立命的根本，是有著過硬的技術實力。那麼如何才能做到高效率的開發進而產生高質量的交付呢？我們們來看一下 Winter 大大價值幾千萬的認知~~
工具鏈
首先，要形成工程體系，建立一套屬於自己的工具鏈。所謂工具鏈，包含兩層含義。工具，顧名思義，是用來幹活的，此處要乾的活是為了生成可以執行的程式或庫檔案；鏈，即鏈條，之所以能稱之為鏈條，說明不止一個東西，然後，按照對應的邏輯串起來就成了我們所說的工具鏈。
工具不是一個獨立的個體，它們之間是有協同，有合作的。工具鏈是在每一個大型開放原始碼專案（包括 Linux 核心本身）背後默默支撐的力量。它們由一組必要的工具和軟體構成，用於編譯和除錯從最小的工具軟體到你可以想象的最複雜的具有 Linux 核心特徵的各種軟體。
在一套工具鏈中最核心的就是專案初始化（Init）、專案啟動（Run）、測試（Test）以及專案的釋出（Publish）四個節點。在一個專案啟動前，就必須要想清楚這四個節點要用什麼樣的工具去實現。
需要注意的是，在工具鏈的使用過程中需要建立一個資料統計體系，在使用過程中有問題可以及時反饋而不是自己默默的想辦法解決，你不是紅領巾，做好事要留名。
另外，經過資料的分析可以清晰的定位哪些工具是大家常用的，哪些是基本不用的，後續可以根據這些資料對常用的工具進行優化，淘汰不常用的工具。
微軟資深工程師 Scott Hanselman 說過，“對於開發者而言，最有力的工具就是自動化工具”（The most powerful tool we have as developers is automation）。工具鏈的打通使得開發者們在交付軟體時可以完成生產環境的構建、測試和執行；正如 Amazon 的 VP 兼 CTO Werner Vogels 那句讓人印象深刻的話：“誰開發誰執行”。（You build it, you run it）。
持續整合
其次，要做到持續整合。持續整合是客戶端發明的一個概念，它裡面有兩個核心的概念，Daily Build 和 BVT。那麼什麼是持續整合？在軟體工程中，持續整合（CI）是指將所有開發者工作副本每天多次合併到主幹的做法。怎麼樣才算是“持續”？對於一天需要整合多少次，並沒有一個明確的定義。一般就是按照自己專案的實際需要來設定一定的頻率，少則可能幾次，多則可能達幾十次。持續整合的優勢在於：
- 減少等待時間：持續整合縮短了從開發、整合、測試、部署各個環節的時間，從而也就縮短了中間可以出現的等待時間。
- 解放了重複性勞動：自動化部署工作可以解放整合、測試、部署等重複性勞動，而且機器整合的頻率明顯可以比手工高很多。
- 更高的產品質量：整合伺服器往往提供 Code Review、程式碼質量檢測等功能。對程式碼不規範或者有錯誤的地方會進行標識，也可以設定郵件、簡訊等進行告警。而開發人員通過 Code Review 也可以持續提高程式設計的能力。
近幾年，伴隨著前端技術日新月異的發展，前端開發中前後端分離，工程化，自動化等現代化的開發模式越來普及，前端專案也引入了編譯，構建，單元測試等現代軟體工程化的標準環節，這樣大大提高了前端的開發效率和業務交付能力。
前端持續整合主要包含 Check-in Build 和 Lint + Rule Check 兩部分。其中，Check-in Build 就是每次提交程式碼都 Check 一次，及時發現問題，Lint 指的是程式碼規範的校驗，Rule Check 包含了業務相關的檢查，DOM 相關的效能方面的檢查（例：頁面上一張圖片的體積過大）以及 JS 報錯方面的檢查。
說白了，前端持續整合就是把程式碼測試、打包、釋出等工作交給一些工具來自動完成。這樣可以提高效率，減少失誤，開發人員再也不用關心程式碼 Push 以後的事情，寫程式碼更加專注和自信。
技術架構
最後，要建立一套 高複用性的 技術架構。
客戶端架構主要是用來解決軟體需求規模帶來的複雜性問題的；服務端架構主要是用來解決大量使用者訪問帶來的複雜性問題的；而前端架構主要是用來解決大量頁面需求帶來的重複勞動問題的。
那麼，問題來了，前端架構是如何解決大量頁面需求帶來的重複性勞動的問題的呢？下面將從庫、元件、模組、搭建系統、全棧方案五個方面來闡述：
-
庫指的是有複用價值的程式碼，例如開發過程中經常會用碰到 URL 解析、AJAX 請求、ENV（用於判斷當前屬於什麼環境）等問題，這些程式碼可以封裝在方法庫中，方便呼叫。
-
元件指的是 UI 上多次出現的元素，例如輪播、Tab 等，元件可以在頁面上多次複用。有句話怎麼說來著，元件複用一小步，開發提效一大步。
-
模組指的是經常被使用的業務模組，例如登入模組，它的特點是隔離性比較高，可以做到即插即用。
-
搭建系統包括模板化搭建和模組化搭建。我們在 前端工程實踐之視覺化搭建系統（一）中分享過我們政採雲的基於業務元件快速生成頁面的搭建系統，它把已經成型的元件像樂高玩具的零件一樣，使用拖拽的方式組裝成最終的頁面，同時能夠讓各個業務快速的接入，提升人效，節約成本。
-
全棧方案包括框架和組建體系兩部分。框架的建設與體系的元件與團隊息息相關，對於這兩點只需定義兩個關鍵詞 面向未來 和 面向場景。
-
在有了庫、元件、模組、搭建系統、全棧方案這些“武器”後，前端架構就能輕鬆的解決大量頁面需求帶來的重複性勞動的問題。
前端團隊的核心——業務價值
大部分技術同學都會認為，個人技術是核心競爭力，那隻要安安心心做技術就好了，管什麼業務？我的技術好了，業務方肯定會乖乖來用我的系統的。這種想法當然是有道理的，技術是我們的立身之本，這是一定要抓好的。但是，如果只這樣去思考問題，那麼你是很危險的。因為，你會發現，很多同學不僅技術好，同時也具備良好的產品思維和業務推動邏輯的能力，比技術更重要的是思維的轉變。
資料驅動思考方式的方法論
在做專案的時候，首先要分析業務，結合一些資料指標，制定一個合理的目標。接著要採集一些資料，建立資料展示系統，資料能幫助我們精準的定位業務的痛點、難點。有了這些前期準備後，就可以制定技術方案。之後就是按照既定的方案從小規模實踐到推廣全公司落地再到形成制度。最後，在一個專案完成後，覆盤，對資料進行分析，總結經驗與不足。
淘寶詳情頁優化背後的故事
淘寶和政採雲一樣都是做電商的，電商公司都遵循這樣一個規律：成交 = 訪問量 * 轉化率 * 客單價，淘寶團隊經過小規模的實驗：通過一個完全沒有改變功能純粹提高效能的小版本的上線，對資料進行分析，發現載入時長的曲線下降一個臺階，使用者的訪問率上升了一個臺階，形成了一個黃金交叉，證明了效能與轉化率是強關聯的。
頁面的載入時長是頁面效能的一個重要指標。有一個指標叫秒開率，關於秒開率，有一個 1秒鐘法則 的說法：2G 網路 1秒進入頁面，3G 網路 1 秒首屏，4G 網路 1秒頁面載入完畢。當時淘寶就是以秒開率作為資料指標，自從有了秒開率，大家工作都有了動力，提效很高。
前端團隊的亮點——技術驅動創新
Weex 在雙十一專案中，參與並支撐了的移動端主會場介面展示和動態處理。在雲端實現了天貓前端運營釋出系統“斑馬”的對接，在前端開發實現了主會場的介面模組和業務邏輯處理，同時在客戶端上對接了手機天貓、手機淘寶。想做到這些，光憑一個好的創意和想法、或憑藉員工超強的執行力、或靠砸錢砸機器，都是沒有辦法做到的，這個問題需要技術驅動力來解決，也就是我們這裡所說的技術驅動創新！Weex 的誕生正是技術驅動創新的結果！
Weex 的前世今生
Weex 是一個動態化的高擴充套件跨平臺解決方案，實現思路來源於 RN 與 Vue。官方文件：什麼是 Weex? WEEX 是由人稱 Vue 的亞洲第二狂熱粉（亞洲第一粉是日本一哥們，做了一個 Vue 的日本整站，哈哈）的勾三股四（原名：趙錦江）牽頭，一期開發成本 10 人客戶端團隊，2 個月專職開發，後期開發成本 20 人（峰值 40 人以上）客戶端專職團隊。 Weex 相對 Web 來說有一個體驗升級，對於客戶端來說 Weex 又是一個動態搭建的方案。
Weex 的業務價值
Weex 的業務價值在於開源 P/R、大促 Native 化。Weex 團隊在整個雙十一的籌備過程中和需求方進行了深入的溝通和交流，並拿出了切實有效的技術方案，很好的解決了其中的很多關鍵環節問題，並且 Weex 作為一個新的技術方案很好的經受住瞭如此重要的“考驗”！
總結
從公司的角度來看，衡量一個前端團隊價值的方式是相似的，前端團隊的基石是質量和效率。在此基礎上，區分前端團隊的核心因素是業務價值，對於少數前端團隊，可能還會為公司和行業帶來創新。
感謝各位的閱讀，有任何建議和意見都可以在下方留言，小編定當積極改正。
活動照片展示
參考文章
招賢納士
政採雲前端團隊（ZooTeam），一個年輕富有激情和創造力的前端團隊，隸屬於政採雲產品研發部，Base 在風景如畫的杭州。團隊現有 50 餘個前端小夥伴，平均年齡 27 歲，近 3 成是全棧工程師，妥妥的青年風暴團。成員構成既有來自於阿里、網易的“老”兵，也有浙大、中科大、杭電等校的應屆新人。團隊在日常的業務對接之外，還在物料體系、工程平臺、搭建平臺、效能體驗、雲端應用、資料分析及視覺化等方向進行技術探索和實戰，推動並落地了一系列的內部技術產品，持續探索前端技術體系的新邊界。
如果你想改變一直被事折騰，希望開始能折騰事；如果你想改變一直被告誡需要多些想法，卻無從破局；如果你想改變你有能力去做成那個結果，卻不需要你；如果你想改變你想做成的事需要一個團隊去支撐，但沒你帶人的位置；如果你想改變既定的節奏，將會是“ 5 年工作時間 3 年工作經驗”；如果你想改變本來悟性不錯，但總是有那一層窗戶紙的模糊… 如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望參與到隨著業務騰飛的過程，親手推動一個有著深入的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我覺得我們該聊聊。任何時間，等著你寫點什麼，發給 ZooTeam@cai-inc.com
