技術棧：小菜前端的技術棧是如何規劃和演進的

摘要： 前端 Leader 行動指南。

• 原文：技術棧：小菜前端的技術棧是如何規劃和演進的
• 做者：Scott

Fundebug經受權轉載，版權歸原做者全部。

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬抗，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream。

本系列共 15+ 篇 - 點此連接，此爲第一篇，你們看完轉發下朋友圈我就心滿意足了。

正文開始

作規劃、管人、管資源、管優先級，這即是一個 Tech Team Leader 的宿命。

本文 Scott 以管理者的視角，與你們分享下我自 2017 年 7 月入職小菜後，與前端同窗一塊兒是如何規劃團隊的技術棧的，這條技術棧上的技能點又是如何在不一樣童鞋不一樣業務中生長出來的。

先來看一張圖：

這張圖是 2018 年 8 月份我爲團隊制定的技術棧架構分工圖，上面基本涵蓋了 2018 ~ 2020 年團隊所須要的的技術棧能力，它也會隨着業務和團隊不斷的微調和修正，等到了 2019 年 8 月份我會從新梳理一個新版本，未來到這裏分享給你們。

在帶這個團隊的一年多時間裏，我對於團隊的構想其實發生了不少次的變化，抽象的通用一點，一共會有兩個並行的過程，一個是從人和團隊視角的作好團隊規劃與管理，一個是結合業務針對團隊作具體的技術棧的演進和架構路線調整，兩個過程會交叉實施互相影響。這些方法和結論也有它特殊的公司背景和侷限性，未必適用於你們所在業務形態下的團隊，千萬不要硬搬，能夠關注下這些過程當中的變化，以及個人思考過程，最終咱們再回到上面的這張圖上，你們就能明白一個團隊的技術棧架構和演進背後的方法論了。

1、團隊管理

首先說團隊管理，這個是前提，沒有配套的團隊管理手段輔助，是很難單純的讓技術棧發生持續的好的變化，也很難將架構理念推動落地的，在團隊管理這裏我主要是分紅四步走。

第一步 瞭解團隊的長與短

新加入到一個團隊，尤爲是成爲資深工程師後新帶領一個團隊，除了埋頭作事外，有一個很重要的事情要儘早作，那就是去了解團隊，方式有不少，好比：

• 主動去看團隊倉庫裏的歷史代碼，瞭解你們的編碼水平，編程風格，工程維護的方式，架構的成熟度
• 與每一個同窗單獨聊聊天，聊聊他對於一個技術的見解，對於業務上思考，對於本身和所處團隊的認知
• 請你們去吃吃飯，聽聽你們都聊什麼，玩什麼，關注什麼，每一個人的氣場和表達方式，在辦公桌和餐桌上有什麼不一樣
• 找服務端團隊和業務團隊的同窗，問問他們對於前端團隊的印象，對於合做童鞋的見解
• 在會議上拋出一些問題，觀察你們的參與積極性和表述觀點的深度

還能夠一塊兒去打遊戲看電影，一塊兒參加公司活動等等，這是一個比較粗的瞭解，我進團隊後，也是挑了上面兩三種方式對團隊成員有了一個比較粗的摸底，看到了不少好的特徵也看到了很多問題。

好的方面：都很年輕很聰明，學習能力較好，可塑性都很強，沒什麼城府，對技術有激情也有熱情，技術棧很新穎，每一個人潛力都很大。

基於這些，能夠預判這個團隊只要理清楚每一個階段的重點，就能夠快速成長，每一個人都能不斷的突破天花板，因此大盤子的性質不錯，資質也不錯，再來看看問題：

問題：職場的專業度不夠，比較情緒化，對於業務多變有必定抵觸，職業規劃無感知，對於好的很差的評判標準比較狹隘比較封閉，總體工具化工程化以及基建的方向都沒有太多思考，對於整個行業的判斷比較粗淺，屬於比較原始蠻荒的階段，團隊成員的能力層次不齊，補位與大局意識比較薄弱。

具體的方法論，能夠把近幾周的問題作彙總，而後給它們打標分類，好比這樣：

結合業務和開發過程，來梳理問題共性，最終的問題能夠總結爲：

• 人心不穩定
• 技能短板多
• 職業無規劃
• 合做意識差
• 團隊無規範
• 工具基建弱
• 業務無感知
• 梯隊未搭建

基於這些，能夠預判團隊須要一個不短的磨合期，在磨合期中須要先逐步創建信任，同時針對不一樣的問題須要學唐僧跟你們常常講多講，也就是經過灌輸讓你們先有一個正確作事的概念在腦海中，而後再針對每個同窗的特徵，以不一樣的方式分配任務，驅動和輔導，另外，須要有一些事情你們要一塊兒作來造成團隊協力和凝聚力，我最終選擇了技術分享做爲一個你們共同作的事情，讓團隊在這一件事情達成惟一的共識 - 技術團隊影響力的提高和我的總結能力的提升。

第二步 鞭策團隊完善內部短板

所謂內部短板，就是徹底是本身的鍋的問題，好比發佈系統不完善，好比代碼不規範，好比工具不健全這些都是甩都別想甩出去的鍋，有了第一步的總結概括後，就能夠在這些問題裏面，優先挑選跟業務有強關係的問題重點突破。

我當時選擇的是開發的上線流，也就是從開發到發佈這個開發團隊必須具有的剛需能力，從這條線劈出來各類工具和系統，童鞋們的反對聲音會相對低，並且因爲系統的效率和穩定性能帶來更多的資源釋放，也能帶來參與同窗的極大成長，因此經過規範和工程的方式來彌補內部短板，是一個很是可取的團隊管理手段，見下圖，是從 2017 年下半年以後到 2018 年，在開發上線流程上發生的變化：

這一路的基建過程大概陸續進行了半年多，基本團隊裏最人肉最髒最累的活兒，都由機器作掉了，雖然跟業務沒有直接關係，但它間接保障了業務的可持續性和穩定性，同時一路升級打怪，也讓參與開發的小夥伴們都有較大的編程和工程能力提高，成爲最先的一批技術骨幹。

第三步 推進團隊邁向無主之地

若是已經解決掉了團隊的核心內部問題，接下來就能夠把跟產品，運營、業務有關係的環節完善掉了，好比 App 在線上運行的異常監控這些，實際上在創業公司，通常是沒有一個部門直接對它負責的，你們都焦點在業務上，那麼這時候從前端團隊手裏出去的做品，理應由前端本身驅動本身來爲它負責，這裏我把線上運行時的監控單獨做爲一條線，它配合內部問題的 Mock 階段的 GPM（GraphQL 數據聚合服務層），都是跨出了前端團隊的職能，與其餘團隊產生了關係，見下圖：

不只對業務，對於其餘的中臺部門好比人事、財務和行政都是同樣，只要有精力，均可以儘量用成本最低的技術手段，來爲公司內三無論的無主之地作一些協同的工具和系統，這會給團隊帶來不少正向的口碑，同時也有技術的提高，最重要的是，在內部問題和外部協同上，一旦你成爲發起者和驅動者，你的角色和身份就發生了變化，你既是產品經理也是項目經理，既是需求方也是業務方，對於我的的綜合能力會有很大的提高，對於整個團隊在公司內部的影響力提高也有幫助，在工做中部門之間互相幫助也打下了一些底子，這一點對於不善表達比較木訥的工程師團隊頗有意義。

第四步 鼓勵團隊技術與業務創新

從前面的三步，你們能夠看出個人套路，帶團隊往前走，比較穩的方式就是從內到外，從技術到跨團隊事務到業務，最終也就是第四步，再回歸到業務和技術的結合，來利用技術創新驅動業務，利用業務可能性倒逼技術突破，這雖然不是終極態，但對於工程師團隊已是一個很是可接受的狀態了。

差很少在 2018 年 5 月份開始，我開始 push 前端團隊把一隻腳邁進到業務中，不管是技術預研，仍是業務場景挖掘，咱們在作好業務支撐的同時，絞盡腦汁去思考，到底這麼多這麼酷的前端技術，怎麼跟個人業務產生關係，怎麼挖到產品經理挖不到的地方，另闢蹊徑爲業務創造可能性，那麼在這一點上由於會觸及公司的核心商業機密，我接下來就舉一個早期的脫敏案例供你們感覺。

在咱們的移動生態都是 App 的時候，微信生態也在蓬勃生長，那麼若是產品延展到了小程序，咱們將如何支撐，要知道此時全公司都沒有任何一個業務包括產品有過相似的具體規劃，但你們都有一些很虛的想法和概念丟進來，這時候工程師經過與業務方出差去用戶現場，去評估有沒有小程序落地的可能性，回來後咱們開始作小程序的技術預研，經過這個過程，咱們搶在業務和產品前面，作了必要的技術儲備，從而爲後來快速打開微信生態，進入小程序的新載體陣營打下了關鍵的技術基礎。若是工程師在這時候沒有主動進入業務的意識的話，也是徹底不可能讓業務方有信息甚至有意願來進入一個新的生態的，因此等到團隊裏的部分工程師都能成長出這種意識和能力的時候，我認爲就是一個合適的時候，來作技術棧的長遠規劃了。

2、技術棧規劃

在我帶團隊的前面 10 個月，其實我也嘗試作過零碎的技術棧規劃，但效果並不盡如人意，一個是客觀基建基礎不知足，很難作相對可靠可落地的規劃，一個是團隊成員的總體意識包括我的能力沒有上來，這時候作有點適得其反，甚至會引發組員的抵觸情緒，總結下就是必要的小的相對零碎的技術規劃必定要有，但不建議垮大週期作大而全的，能夠作 1 ~ 1.5 年左右的。

ReactJS - 第一次大規模應用技術棧歸一

不管是 RN，仍是 PC 端的 ReactJS，小菜前端的 React 技術棧在頭三年就實現歸一了，只是歸一而不規範，以及還有舊 App 是原生架構這樣的歷史包袱，但整體上到 2017 年下半年，React 技術棧外加 Webpack 是團隊的標配了。

這條歸一的技術棧結合後面的 NodeJS 能力，也就孵化了咱們的兩個核心前端框架：

• 客戶端 RN 框架 Brick
• PC ERP 單頁框架 Highway

NodeJS - 第二次大規模技術棧鎖定歸一

咱們再回到 NodeJS，也就 2017 年初是初步使用，2017 年末是深度使用，從 2017 年末開始，NodeJS 就成爲了團隊的一個核心能力，經過它，咱們把 RN 的基建全家桶一條龍所有實現了，好比腳手架，組件化，代碼校驗，機器打包，支持白名單的熱更新發布，包安裝成功失敗與跟蹤，端用戶訪問行爲數據可視化，端運行異常監控與指派等等，這一條龍讓咱們有信心來把全部的 App 所有重構爲固定的 RN 版本最新的路由，

除了支撐客戶端基建，NodeJS 還爲咱們打開了內部系統開發的一扇門 - 服務端能力，這扇門對於前端對於公司都是有極大好處的，從前端的角度，能夠掌握更多技能能夠支撐更多業務能夠把技術玩的更 6，從公司的角度，在不大規模動用先後後端產品和運營的資源下，前端工程師能夠獨立完成跟業務相對不那麼強耦合的業務，又省錢又省時間，是很是划算的投入產出比。

那麼在 NodeJS 這個技術棧上，咱們長出了不少能力，爲業務提供了大量幫助，對於團隊而言，沉澱了一個核心的服務端框架：

• Node 服務端（基於 Egg）框架 Cross

之因此研發 Cross， 是由於咱們一路用 ExpressJS/KoaJS/ThinkJS 過來，框架的定製升級和集成咱們想要複用的功能都不夠規範，也不夠嚴謹，直到咱們使用 EggJS，基於它的強約定和插件機制能夠方便的集成過來，來定製咱們本身的框架，咱們再 2018 年下半年開始啓動這個框架的定製直到年末出爐。

GraphQL - 第三次小規模的技術棧嘗試

GraphQL 必定會成爲 2019 年相對高頻的詞彙出如今你們的視線裏，咱們是從 2017 年開始使用，同時在 2018 年 4 月份直接研發了聚合數據服務系統，集成到了咱們的網關下面，爲各個 App 端提供定製數據的能力，咱們嚐到了不少甜頭，也遇到了很多阻力和調整，在 2019 年咱們會持續的耕耘它，至少在特定的領域內大規模使用。

還有一些數據蒐集、加工計算和可視化的一些組裝層咱們是交給了 Python 和 C#，甚至是 Rust 的嘗試，這些均可以看作是技術預研，還不能稱爲咱們的核心能力，因此暫時不做爲核心技術棧的演進目標。

MPVue/Vue - 第四次大規模的小程序技術棧歸一

若是說 GraphQL 是咱們遇到的一個驚喜的彩蛋，那麼 Vue 則是一個讓咱們驚訝的彩蛋，咱們本來的演進路線裏並不包含它，但限於咱們業務的複雜度，和當時市面上可選擇的侷限性，咱們最終選擇了 MPVue 做爲咱們的小程序框架載體，那麼也天然沒有考慮京東的 Taro，那時候 Taro 還太青澀沒法在生產環境用，雖然使用 MPVue 給咱們帶來了不少可能性和效率，它也爲咱們帶來了困擾，那就是技術棧在團隊內出現了必定程度的割裂，畢竟它跟 React 的語法和生態不一樣，到目前爲止，基於小程序的生態，咱們把 MPVue 做爲核心的小程序技術棧，基於這樣的一個端領域實現了歸一。

那麼整體全篇下來，會發現咱們的技術棧演進，是會隨着團隊人員能力基建成熟度，也就是必定的團隊管理和成長而變化的，同時也會跟咱們的業務及生態有強關聯性，除此以外，技術棧規劃確實是一個看着很客觀但實際上也比較主管的工做，它裏面雜糅了不少的因素，這些因素在不一樣時期的權重還不一樣，當團隊能力強的時候，能夠規劃的長遠一些硬核一些，團隊能力弱的時候就要靈活一些。

因而從 2018 年下半年開始，我開始作相對硬核的技術棧和架構規劃，也就是有開篇的這張圖：

一共是這十二個課題和方向：

• Node 服務，支撐工具、業務系統、運維、監控等
• 前端基礎框架，支撐將來幾十個甚至上百個 PC/H5 ERP/Saas 工具系統
• 先後端協同方案，支撐特定業務領域的數據聚合，下降開發成本
• 端行爲數據監控，爲業務/產品/運營提供產品設計及業務調整決策
• 端性能監控跟蹤，爲端可靠性穩定性提供保障
• 端數據計算中心，爲可視化、圖形圖像及視頻多媒體提供高性能計算服務
• 構建部署，爲多端提供總體開發、測試、打包、發佈部署提供運維能力
• 客戶端逆向，爲社羣/CRM/人與人新的連接關係提供必要的技術底層方案
• 安全防控，爲全端提供安全監測、警報、攔截等護航保障
• 平臺組件化，爲跨端提供低成本可複用的 UI 組件及將來的智能化拼裝
• 交互研究，爲交互體驗、ABTest、用戶行爲價值、設計表達輸出工具與方法論
• 端/數據報表透視與可視化，爲全公司提供友好的可快速產出與維護的報表可視化方案

這些課題向下，再延展出各個技術棧的方向規劃，就是當前團隊內咱們開始並持續關注的事項了，接下來的技術棧也會順着這些課題方向而不斷的演進升級。

最後，業務支撐、技術價值、我的成長、組織升級這幾者之間的確很難達到理想中的平衡的，但基於創造更多的業務價值這一核心立論，不斷去尋找場景尋找突破點的這樣的 action 是咱們做爲管理者和技術骨幹所要堅持到底，不管什麼時候，這都是優秀的工程師和技術決策者的責任和宿命 - 爲人負責，併爲結果負責，借事修人，借人成事。

最最後，本文做爲預熱篇，旨在針對以下話題爲你們輸出：

• 把團隊蠻荒到自動化運維的從 0 到 1
• 成長曆程總結輸出給社區，幫助更多的小團隊少走彎路
• 以一種可被量化的方式匯聚小菜前端的困惑、沉澱與方法路徑，給團隊帶來更多創做成就感
• 從更多視角側切進入團隊管理/技術演進/我的成長的過程當中，探討工程師團隊的價值最大化

若是你們感興趣，咱們小菜前端團隊，會集體智慧共同凝聚，一塊兒撰寫並推出一本偏前端職業生涯、技術成長和團隊成長的小冊，回饋給你們，你們在文後記得留言評論和提需求哦。