技术栈：2015~2019 小菜 4 年技术栈进化回顾

本文主要是介绍技术栈：2015~2019 小菜 4 年技术栈进化回顾，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

著作权归作者所有。商业转载请联系 Scott 获得授权，非商业转载请注明出处[务必保留全文，勿做删减]。

早期汽车诞生取代马夫的时候，政府颁布命令让汽车限速在 4 英里，要有三个人驾驶，其中要有一个人专门摇摆小红旗给汽车开道，而随着特斯拉电动汽车诞生后，对于汽车的共识，就变成了 “4 个轮子 + 1 块电池 + 1 台电脑”，甚至无人驾驶，这就是技术进步的力量。

2014 年，互联网已整体进入移动化进程，各种创业 App 满天飞，小菜的前端团队也是在这样的一个时代背景下开始组建，而小菜的业务团队需要多地联合移动办公，对敏捷和效率有更高的要求，从 2015 年开始，内外部的产品和协同工具也都选择了 App 这种载体，直到今天协同工具全部移动化，主阵营也从 App 扩展到了小程序、H5、公众号，甚至涵盖 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，否则在公众号上直接转载，尤其是裁剪内容后转载，我都会直接进行投诉处理。

这篇关于技术栈：2015~2019 小菜 4 年技术栈进化回顾的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！