技術棧：2015~2019 小菜 4 年技術棧進化回顧

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

早期汽車誕生取代馬伕的時候，政府頒佈命令讓汽車限速在 4 英里，要有三我的駕駛，其中要有一我的專門搖擺小紅旗給汽車開道，而隨着特斯拉電動汽車誕生後，對於汽車的共識，就變成了 「4 個輪子 + 1 塊電池 + 1 臺電腦」，甚至無人駕駛，這就是技術進步的力量。

2014 年，互聯網已總體進入移動化進程，各類創業 App 滿天飛，小菜的前端團隊也是在這樣的一個時代背景下開始組建，而小菜的業務團隊須要多地聯合移動辦公，對敏捷和效率有更高的要求，從 2015 年開始，內外部的產品和協同工具也都選擇了 App 這種載體，直到今天協同工具所有移動化，主陣營也從 App 擴展到了小程序、H五、公衆號，甚至涵蓋 PC 網站等配套基建基礎，這幾年技術棧發生了巨大變化，能夠參考下面這張刻度比較粗的時間軸：

本文寫於 2018 年末，發表於掘金小冊中，做爲開篇，能夠跟隨小菜前端的視角，快速回顧下促成這些變化的背景，以及不一樣的技術棧帶來的優點和挑戰，也瞭解下這個團隊這幾年技術上的變化。

蠻荒時代 · jQuery + 原生

[從無到有]創業初期，無前端工程師，服務端 + 外包

公司最初的業務試點是從城市的一批蔬菜市場以場內採買的方式，把蔬菜售賣給二批的商戶，須要大量的地推銷售，採購和物流人員，而售賣必然須要一個交易平臺，因而 宋小菜 這個 App 就呼之欲出，蠻荒創業的時候天然沒有太多技術積累也沒有足夠的時間準備，因而就上了一個網頁版的混合 App，也就是原生殼裏面嵌了一個瀏覽器，瀏覽器的網頁選擇 jQuery 做爲 DOM 和事件庫，爲用戶的下單購買提供交互能力，這固然是一個過渡方案，由於內嵌網頁的性能在幾百塊的安卓機器上表現很不理想，體驗不好，對於業務來講就是勉強能用。

除了一個支持交易的移動 App 外，須要對採購、訂單、物流作精細化管理，那麼天然須要一個 PC  版的 ERP 系統，這個系統最初也是找外包公司開發的，後端是 Java + VM，前端是繪製頁面，JS 庫依然是 jQuery，不管先後端，代碼質量到系統架構都很是粗糙原始，隨着公司總體技術升級，最初的架構也從歷史小包袱變成了歷史大包袱，甚至出現過一些重大的安全漏洞，幸運的是，蒸汽時代很快到來。

冷兵器時代 · jQuery + 原生 + RN

[造成戰鬥力]創業早期，客戶端工程師 + 前端工程師 <= 3 名

隨着公司業務規模擴和模式的升級，一個體驗差的 App 顯然不能很好的支撐業務了，此時依然是 2015 年，咱們看到了 Facebook 開源的 ReactNative，也就是 RN - 全套 JS + 部分原生組件就能夠快速搭建出一個移動 App，因而蘋果版本的 App 咱們就用 RN 實現了，而 Android 就沒這麼幸運，由於早期 RN 的 Android 從不支持到支持也經歷了一段時間，而且支持的很不完善，因而 Android 的宋小菜用原生也就是 Java 重寫了，而 iOS 的宋小菜用 RN 重寫了。

除了交易的 App，採購，銷售團隊與客戶關係的管理也成爲了剛需，否則徹底靠線下的 Excel 和 ERP 根本沒法響應 toB 業務中的時效性，因而第二款和第三款 App 誕生了，服務於採購的採祕與服務於銷售體系的 CRM App - 宋小福，這兩款 App 都是用 RN 開發的。

在這個時代，線上的 App 先後端已經徹底分離，但後臺的接口設計還很青澀，一樣前端的 RN 框架應用也很是暴力，大量的全局變量注入與引用，大量的三方包直接魔改丟到 node_modules 隨 git 倉庫一塊兒走，大量的 UI 組件在多個 App 裏面拷貝來拷貝去，雖然 JS 的語言語法棧咱們用的是 RN，都是最新的語法特性，但在整個工程層面就像漿糊同樣混在一塊兒很難維護，這就是這個時期的特點，既超前又混亂，多種前端技術方案混用，編程思想和工程組織混亂。達摩之劍雖然手，從內功心法到招數卻沒法合二爲一，就像謝遜拿着屠龍刀，勇猛但不得真諦。

蒸汽時代 · jQuery + React + RN + 原生

[初步解放生產力]創業前期，客戶端工程師 + 前端工程師 <= 6 名

隨着 RN 的持續應用，App 端的開發效率獲得了量級的提高，烏煙瘴氣的冷兵器時代很快結束，進入了挑戰更高的蒸汽時代，這時候已是 2016 年了，採配銷中的採和銷有了，CRM 客戶工具也有了，尚未配送工具及服務供應商的工具，因而新增兩款 App - 服務於物流配送司機的宋小倉和服務於供應商的賣大蔬，這些新的 App 都使用 RN 開發，從架構體系上基本統一了，ERP 後臺也從 jQuery 逐步切換到了 Webpack + ReactJS。

技術棧逐步統一後帶來的好處很明顯，能夠用不多的人持續的快速支撐業務的調整，這一點對於 toB 這樣對效率和成本很是敏感的創業團隊來講很是關鍵。不管是新開 App，仍是已有的 App 上面增長業務模塊，後端給接口，前端拼頁面，業務節奏和開發節奏今後進入雙快時期。

在沒有基建基礎和規範保障的時候，伴隨快而來的就是無序和風險，這就是這個時期的特色，全部的 App 雖然有獨立的倉庫，但倉庫之間的組件代碼並無實現真正意義的共享，而是經過拷貝的方式來複用代碼，並且路由、定位、頁面容器甚至工程結構都差別很大，RN 框架的主版本也相差甚遠，這個給新人帶來巨大的學習成本，也給團隊本身帶來了巨大的維護成本，一旦業務進入穩定器，對性能、穩定性和可維護性有了更高的需求，這些暴露的問題就變得致命。

電氣時代 · React + RN + Node + GraphQL

[進一步解放生產力]創業中期，前端工程師 <= 9 名

人類有了電之後，文明進化的速度瞬間開掛，而小菜前端的電就來自於 NodeJS，咱們使用 RN 來搭建 App，是由於它從開發成本到打包構建都很是敏捷，更重要的是它能夠支持熱更新，在不向蘋果商店及 Android 渠道提交版本的前提下，就能實現 App 內的功能更新，也即發佈不發版，這一點對於業務以周爲單位發生變化的創業團隊簡直是救命藥，因此 2017 年，咱們用 NodeJS 搭建了本身的 RN 熱更新平臺，這是第一次近距離嚐到甜頭，但嚐到甜頭的同時也帶來了不少問題，尤爲是在蒸汽時代的不少問題純靠人肉都是沒法解決的。

盤點創業到 2017 年，幾乎全部的前端基建都是 0 的狀態，此時有點像是權力的遊戲中的多斯拉克部落，做戰英勇兵力也充沛，但配套的攻城設備、高階攻略與工具都沒有，同時你們都比較心高氣傲，這也是多斯拉克被無垢者整齊劃一的軍團戰勝的一個關鍵緣由，下圖是 2017 年下半年梳理的，從工具、規範到業務基建的問題截圖：

來舉一個例子，好比業務基建的報表場景，是須要先後端配合的，後端寫各類 SQL，而後輸出接口給前端，先後端要在幾十個字段的命名、意義、單位上徹底達成共識，而後才能在前端的 table 裏輸出無誤的報表，這個報表可能還得支持日期時間段的檢索和排序，這時候接口上就須要增長上多個參數來向服務端傳遞用戶的操做動做，這樣一個報表一般開發週期是 1 到 3 天，每次須要先後端團隊各自排期，進入評審，再開發測試和最終發佈，以及後期的維護升級，對於 [數據即真相，決策即生死] 的業務決策層來講，公司跑了 3 年，纔開發了50 多張報表，決策時間永遠都是滯後的，這樣的問題顯然是致命的。

針對這個問題，前端工程師把這樣的報表作成了可 SQL 正反拼裝，結合 GraphQL 實現自動展現的系統後，報表在以後 1 年就快速產出了 200 多張，全部的業務方都豎起了大拇指，每個工程師都自豪感滿滿，從心裏深處咱們都深深明白一件事，基建基礎即核心能力前提，基建核心能力即 NodeJS 開發能力，而只要碰到 NodeJS，便會帶來無數的技術挑戰，這些挑戰會隨着基建體系的進一步搭建，隨着業務規模的鋪張愈來愈多愈來愈緊迫。

電網時代 · React + RN + Node + GraphQL + C# + Python

[生產工具全面升級]創業中期，前端工程師 <= 12 名，前端技術專家 1 名

在電氣時代，咱們從兩個寶物中受益，一個是 NodeJS，一個是 GraphQL，從前的能力都是點狀、線狀的，而把 NodeJS 融入到前端團隊工程化的方方面面之後，再把 GraphQL 這種聚合數據的中間層結合起來，前端的能力就能夠組成一張網了，這張網的正中心是人，最好的變化必定是首先從人開始的，咱們盤點了 2017 年到 2018 年使用 RN 或者依賴客戶端的幾個不一樣時期的創業公司人員與工程師比例，以下圖：

發現咱們團隊依然是處在較爲早期的規模，但總體技術進度已經走向到了一個新的階段，新的階段不是靠等出來的，而是靠瘋狂的基建把效率壓榨出來的，因此電網時代，咱們受限於人力，就 push 團隊的核心成員，技術棧的深度和廣度發生更多質變，從而能空出來必定是資源來持續支撐基建，而基建的成果必定能吸引更多優秀的工程師進來團隊，這樣就能造成一個健康的基建生態，這樣基建、業務支撐、人才成長之間就互相反哺，整個團隊才正式走向正規。

判斷團隊是否走向正規，能夠從業務的支撐程度以及技術沉澱物來評估，下圖是咱們 2018 年 10 月份盤的前端支撐狀況，其中有以下幾個重要的技術沉澱：

• Node 服務框架 Cross，2019 年將支撐十幾個線上系統
• 前端 PC 框架(支持 H5) Highway，2019 年將支持十幾個線上平臺
• RN 的統一路由/組件框架 Brick(圖上未體現)，2019 年將繼續 9 個 App
• 可視化數據報表系統，技術棧 Node + GraphQL + C# + Python，2019 年將支撐全公司業務數據透視

在上圖，咱們特地標出了 人工時代 - 工具時代 - 工程時代 - 智能時代，來對應到以前玉伯提到的前端團隊路線，發展軌跡確實與小菜前端特別吻合，因此咱們前面幾年的技術棧是處在人工時代和工具時代，而如今咱們正在從工具時代跨向工程時代，而工程時代的思惟方式跟以前會有很大的不一樣，這個課題就將伴隨咱們團隊將來至少 2 年，咱們也會把將來 2 年在工程時代的思考，以及部分智能時代的嘗試，在後面不斷的更新進來與你們一同進步。

小結

本篇帶你們快速的 review 了團隊的技術棧發展史，你們腦海中可能已經有了無數的問題想要問，好比 NodeJS 在團隊中具體作了哪些事，基建與業務到底如何平衡，業務與我的成長到底如何結合等等，這些問題咱們所有打散成了一個一個的小課題，在後面的章節中與你們逐個探討，建議你們在閱讀的時候，結合本身所在的團隊，結合本身的職業規劃，結合本身假如做爲管理者會如何選擇，用這種代入感發問更多問題，並最終從咱們的總結中受到啓發，有所收穫。

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