技术栈：如何让团队规划技术栈获得有效落地

全部事情均可分三个版本：正在进行中的 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，不然在公众号上直接转载，尤为是裁剪内容后转载，我都会直接进行投诉处理。