Winter 在政採雲分享實錄 -《前端團隊的成長》

原創不易，但願能關注下咱們，再順手點個贊~~

本文首發於政採雲前端團隊博客： 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 做爲一個新的技術方案很好的經受住瞭如此重要的「考驗」！

總結

從公司的角度來看，衡量一個前端團隊價值的方式是類似的，前端團隊的基石是質量和效率。在此基礎上，區分前端團隊的核心因素是業務價值，對於少數前端團隊，可能還會爲公司和行業帶來創新。

感謝各位的閱讀，有任何建議和意見均可以在下方留言，小編定當積極改正。

活動照片展現

參考文章

• DevOps概念、關鍵問題、工具鏈及文化等詳細介紹

• 前端開發如何讓持續集成/持續部署(CI/CD)跑起來

招賢納士

政採雲前端團隊（ZooTeam），一個年輕富有激情和創造力的前端團隊，隸屬於政採雲產品研發部，Base 在風景如畫的杭州。團隊現有 50 餘個前端小夥伴，平均年齡 27 歲，近 3 成是全棧工程師，妥妥的青年風暴團。成員構成既有來自於阿里、網易的「老」兵，也有浙大、中科大、杭電等校的應屆新人。團隊在平常的業務對接以外，還在物料體系、工程平臺、搭建平臺、性能體驗、雲端應用、數據分析及可視化等方向進行技術探索和實戰，推進並落地了一系列的內部技術產品，持續探索前端技術體系的新邊界。

若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變既定的節奏，將會是「 5 年工做時間 3 年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手推進一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給 ZooTeam@cai-inc.com

推薦閱讀

1024 鉅獻！！一文看盡前端過去一年的精華沉澱（700 篇好文大彙總）

前端工程實踐之可視化搭建系統（一）

自動化 Web 性能優化分析方案