技术栈：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，不然在公众号上直接转载，尤为是裁剪内容后转载，我都会直接进行投诉处理。