所有事情都可分三个版本：正在进行中的 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 的设计终局，这些关注会让自己对技术的判断更加敏感。
总结来说，本着不以捕风捉影的心态去尽可能多的定期关注技术动态，对技术方案有更强的敏感度和成本感知，找更多参考样板公司做差距比对，以及进入自己公司业务中参与更多讨论，从中形成自己对于业务走向和规模化程度的判断，并基于此来畅想团队未来一年左右的技术前景，有了这个前提，就可以做预研了。
技术预研要最小成本实践
当对于所设想的技术有一定的判断后，就可以在适当的时候，比如刚好有同学资源闲置，比如刚好有个项目是小型项目可以用来试错，就可以做预研了。
在挑选人预研时，要谨记两点：
- 要找学习速度最快的技术尖子来做预研
- 要用最小的项目原型来做尝试
- 可以借助第三方（付费）来替代需要自研的部分
这三点非常关键，前者不仅可以最快最容易拿到预研结果，还可以从过程中来观测尖兵上手的速度从而评估他对于普通工程师的上手成本，后者则是要最小程度的侵入到现有的产品体系中，保证最小的副作用和成本，最小的成本不意味着最少的思考，反而是要充分考虑清楚才可以动手，最后还有一点需要额外留意的，就是在动手之前，一定要把真实的流程和问题进来透明化出来，而不仅仅是存放到脑海里面。
2017 年底我们想要启动一个对 RN APP 自动化测试的方案，集成到我们的打包系统中，这样测试或者 PM 可以发起一个测试流程，把关键的测试流程定制后，就可以让机器去自动化打包及模拟测试流程，最终输送一份测试报告出来，我们就把一些过程性的角色和问题点透视出来：
同时把角色之间的合作关系也透视出来：
然后才是付诸实施，实施的时候，能接力就借力，我们就借助了阿里的 MQC 来做模拟和输出报告的过程，最初的流程与技术栈图如下：
可以发现我们把需要第三方的成本也列入进去，这样我们就可以快速的把流程跑通，就算预研失败也影响不大，如果预研成功，就可以选择在适当的时候立项攻坚开发了。
上面提到的这个项目，其实我们诉诸了很大的想象力，也取得了一些初步的成果，但是做的太过于激进（后端稳定的日常环境还没准备好），导致项目最后被搁置，但这样一个最小成本实践的方法论大家是可以借鉴的，我们其他的项目都遵循这样的方式来做前期准备。
落地过程要坚决笃定
决定一个技术规划能否落地，除了预判的准确率外，还有一个非常关键的因素就是这项技术或者方案推进的坚决程度。因为有时候一个方案看着美好，真正实施会遇到很多障碍甚至会走很多弯路。这个过程中会产生很多负面的声音包括压力，一不小心就放弃了导致前功尽弃，所以一旦立项开搞，就坚决不能回头一条道儿走到黑，无论是否成功。
最大的忌讳是：进行立项的过程中受到阻力就开始摇摆，于是放缓推进的速度和力度，这样对整个团队是不负责任的。不仅会影响参与项目同学的工作激情，还会让方案的可行性和成功率大打折扣，最重要的是，可能由于摇摆而让周期很长，从而失去最黄金的技术应用窗口期，从而失去了为业务创造更大价值的机会。
举一个例子，我们当时做小程序时团队是零经验，在经过设想和预研后就坚决把 MPVue 结合测试项目，在两周就做了出来，从而为业务的打法测试打下了基础。这个过程我们顶着巨大的压力，但最终证明这样的坚持是非常正确的，整个公司的业务生态因此而受益。
历史包袱一定要择机重构
技术栈更新一定会带来旧系统的不兼容，比如你有一个 jQuery 的旧系统，过了三四年如果不把它重构掉，后面再招聘新同学进来，就会受到旧技术栈的干扰，如果只会 Vue/React，还要现学 jQuery，并且要慢慢非常熟悉 jQuery，才能对原来基于 jQuery 开发的比较复杂的页面和组件进行维护。如果是团队老同学去维护旧系统，那么自然会占用老的资深同学的宝贵时间去做这些相对挑战度不高的项目，成就感也会大大减弱，所以技术栈更换的周期可以拉长一些，但当整个团队的技术栈都更新上来的时候，旧系统就一定要花人手去把他强行重构掉，除非这个系统非常非常稳定，几乎不再基于它做任何额外开发，那么可以多拖一些年月。
小结
2019 ~ 2020 年的技术栈规划，相信大家已经从前面的时间线上看到了，秘诀就是：技术感知/业务深扎/最小成本预研，以及尽可能打开脑洞。而我们对于未来 1 年所押注的技术栈是：Python/Go/多端采集埋点/Docker/Rust/Android SDK/小程序-H5 统一框架/全链路服务化监控/直播推流转发，也就是这张图上的具体体现：
送个稻谷，支持我写下去👇
若有收获，就点个赞吧
0 人点赞
