技術棧：如何讓團隊規劃技術棧獲得有效落地

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

全部事情均可分三個版本：正在進行中的 v1.0，已規劃且正在預研和調整的 v2.0，正在設想並造成粗規劃的 v3.0，每次完成以後均可以看作沉澱下穩定的技術棧。全部的任務均可以分爲主線和支線：主線打績效，支線玩驚喜，技術棧規劃與執行亦不例外。

本文寫於 2019 年 3 月份，嘗試幫你們梳理下團隊技術棧演進的一些作法，先來看下小菜前端團隊，關於技術棧語言棧（包含框架）的演進結論，幫你們把時間線上的規劃串起來：

2017 年 7 月：

• 進行中：RN / React(PC)
• 預研中：NodeJS(Express / Koa / ThinkJS / Egg) / RN 骨架
• 設想中：GraphQL / RN 組件化 / 腳手架 / 自動化測試

2018 年 7 月：

• 已沉澱：RN / React(PC) / NodeJS(EggJS)
• 進行中：RN 骨架 / 腳手架 / GraphQL
• 預研中：PC 框架 / Node Framework / MPVue / RN 組件化
• 設想中：Python / Rust / Go / RN 框架 / Rust / 多端採集埋點 / 自動化部署 / 視頻流加工 / Docker

2019 年 3 月（當下）：

• 已沉澱：RN / React(PC) / NodeJS(EggJS) / GraphQL / RN 組件化 / RN 骨架 / 視頻流加工
• 進行中：Node Framework / PC 框架(兼容 H5) / MPVue / 可視化 / 自動化部署
• 預研中：Python / Go/多端採集埋點 / Docker
• 設想中：Rust / Android SDK / 小程序-H5 統一框架 / 全鏈路服務化監控 / 直播推流轉發

再來直觀的解釋下：

• 已沉澱：團隊有必定數量的同窗掌握了該技能或者這個方案成熟了進入維護期；
• 進行中：團隊沒掌握好，方案不穩定不完善還須要大量迭代，須要持續推動的；
• 預研中：本地測試和嚐鮮，主要跑原型測試和接入小型項目，未正式立項開發；
• 設想中：結合業務和技術痛點，跑 Demo，看文檔，以腦洞想法和 YY 爲主。

因此對於小菜前端團隊來講，咱們的方法論就是從設想到預研，從預研到進行，最後落地沉澱。有時候設想中的會泡湯或者遙遙無期，好比 Rust 的落地；有時候設想中的會迅速落地，甚至跳過預研，好比可視化與 GraphQL；也有時候已經落地的並無帶來太大價值反而是白白投入，好比咱們早期的自動化測試，但大致上是按照這樣的一套流程來推動整個技術棧的演進的。

接下來咱們來結合這幾個階段，來看看如何提早量的作技術棧規劃和調整。

技術認知與業務理解是前提

設想中的，一般是基於技術的更新週期，要有必定的工具鏈或者語言棧升級。除此之外，更多的是基於業務發展所帶來的新的與用戶對話的場景和方式，預判業務未來可能須要的技術儲備。但這塊須要深扎業務，基於對於業務的長遠理解，才能作出準確率更高的預測。

除了業務，那就是要對技術更加敏感。這個敏感其實有不少簡單的套路去作，好比去調研業務類型相似且規模比本身大的公司，看他們的技術棧現狀，他們要償還的技術債，他們對某個技術的應用程度，以及他們比較領先的技術解決方案。這些訊息能夠靠參加技術大會或者當面溝通來獲取，獲取後固然不能硬抄，須要結合本身的團隊和業務情況看看是否匹配，成本多高價值多大，小菜早期包括如今，從其餘公司中學習到了不少。好比從大搜車的前端和無線架構組這裏學習到了 Node 基建和 ReactNative 組件化帶來的價值，因此也就把 Node 做爲核心技術棧來推動，最終拿到了不錯的結果。

除了調研這種很實用的參考手段以外，其實就是去關注社區開源方案的動向。特別是大公司大項目的大改版背景，看看社區反饋的風向，基於這些官方的小道消息，能夠引起不少基於猜想的思考，好比 Flutter 的野心，ReactNative 的設計終局，這些關注會讓本身對技術的判斷更加敏感。

總結來講，本着不以捕風捉影的心態去儘量多的按期關注技術動態，對技術方案有更強的敏感度和成本感知，找更多參考樣板公司作差距比對，以及進入本身公司業務中參與更多討論，從中造成本身對於業務走向和規模化程度的判斷，並基於此來暢想團隊將來一年左右的技術前景，有了這個前提，就能夠作預研了。

技術預研要最小成本實踐

當對於所設想的技術有必定的判斷後，就能夠在適當的時候，好比恰好有同窗資源閒置，好比恰好有個項目是小型項目能夠用來試錯，就能夠作預研了。

在挑選人預研時，要謹記兩點：

1. 要找學習速度最快的技術尖子來作預研
2. 要用最小的項目原型來作嘗試
3. 能夠藉助第三方（付費）來替代須要自研的部分

這三點很是關鍵，前者不只能夠最快最容易拿到預研結果，還能夠從過程當中來觀測尖兵上手的速度從而評估他對於普通工程師的上手成本，後者則是要最小程度的侵入到現有的產品體系中，保證最小的反作用和成本，最小的成本不意味着最少的思考，反而是要充分考慮清楚才能夠動手，最後還有一點須要額外留意的，就是在動手以前，必定要把真實的流程和問題進來透明化出來，而不只僅是存放到腦海裏面。

2017 年末咱們想要啓動一個對 RN APP 自動化測試的方案，集成到咱們的打包系統中，這樣測試或者 PM 能夠發起一個測試流程，把關鍵的測試流程定製後，就可讓機器去自動化打包及模擬測試流程，最終輸送一份測試報告出來，咱們就把一些過程性的角色和問題點透視出來：

同時把角色之間的合做關係也透視出來：

而後纔是付諸實施，實施的時候，能接力就借力，咱們就藉助了阿里的 MQC 來作模擬和輸出報告的過程，最初的流程與技術棧圖以下：

能夠發現咱們把須要第三方的成本也列入進去，這樣咱們就能夠快速的把流程跑通，就算預研失敗也影響不大，若是預研成功，就能夠選擇在適當的時候立項攻堅開發了。

上面提到的這個項目，其實咱們訴諸了很大的想象力，也取得了一些初步的成果，可是作的太過於激進（後端穩定的平常環境還沒準備好），致使項目最後被擱置，但這樣一個最小成本實踐的方法論你們是能夠借鑑的，咱們其餘的項目都遵循這樣的方式來作前期準備。

落地過程要堅定篤定

決定一個技術規劃可否落地，除了預判的準確率外，還有一個很是關鍵的因素就是這項技術或者方案推動的堅定程度。由於有時候一個方案看着美好，真正實施會遇到不少障礙甚至會走不少彎路。這個過程當中會產生不少負面的聲音包括壓力，一不當心就放棄了致使前功盡棄，因此一旦立項開搞，就堅定不能回頭一條道兒走到黑，不管是否成功。

最大的忌諱是：進行立項的過程當中受到阻力就開始搖擺，因而放緩推動的速度和力度，這樣對整個團隊是不負責任的。不只會影響參與項目同窗的工做激情，還會讓方案的可行性和成功率大打折扣，最重要的是，可能因爲搖擺而讓週期很長，從而失去最黃金的技術應用窗口期，從而失去了爲業務創造更大價值的機會。

舉一個例子，咱們當時作小程序時團隊是零經驗，在通過設想和預研後就堅定把 MPVue 結合測試項目，在兩週就作了出來，從而爲業務的打法測試打下了基礎。這個過程咱們頂着巨大的壓力，但最終證實這樣的堅持是很是正確的，整個公司的業務生態所以而受益。

歷史包袱必定要擇機重構

技術棧更新必定會帶來舊系統的不兼容，好比你有一個 jQuery 的舊系統，過了三四年若是不把它重構掉，後面再招聘新同窗進來，就會受到舊技術棧的干擾，若是隻會 Vue/React，還要現學 jQuery，而且要慢慢很是熟悉 jQuery，才能對原來基於 jQuery 開發的比較複雜的頁面和組件進行維護。若是是團隊老同窗去維護舊系統，那麼天然會佔用老的資深同窗的寶貴時間去作這些相對挑戰度不高的項目，成就感也會大大減弱，因此技術棧更換的週期能夠拉長一些，但當整個團隊的技術棧都更新上來的時候，舊系統就必定要花人手去把他強行重構掉，除非這個系統很是很是穩定，幾乎再也不基於它作任何額外開發，那麼能夠多拖一些年月。

小結

2019 ~ 2020 年的技術棧規劃，相信你們已經從前面的時間線上看到了，祕訣就是：技術感知/業務深扎/最小成本預研，以及儘量打開腦洞。而咱們對於將來 1 年所押注的技術棧是：Python/Go/多端採集埋點/Docker/Rust/Android SDK/小程序-H5 統一框架/全鏈路服務化監控/直播推流轉發，也就是這張圖上的具體體現：

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬扛，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream，也能夠來 關注 Scott 語雀跟進最新動態，本文未經許可不準轉載，得到許可請聯繫 Scott，不然在公衆號上直接轉載，尤爲是裁剪內容後轉載，我都會直接進行投訴處理。