技术栈：小菜前端的技术栈是如何规划和演进的

Scott 近两年不管是面试仍是线下线上的技术分享，遇到许许多多前端同窗，因为团队缘由，我的缘由，职业成长，技术方向，甚至家庭等等缘由，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬抗，你们能够找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdream。

---

本系列共 15+ 篇 - 点此连接，此为第一篇，你们看完转发下朋友圈我就心满意足了。

正文开始

作规划、管人、管资源、管优先级，这即是一个 Tech Team Leader 的宿命。

本文 Scott 以管理者的视角，与你们分享下我自 2017 年 7 月入职小菜后，与前端同窗一块儿是如何规划团队的技术栈的，这条技术栈上的技能点又是如何在不一样童鞋不一样业务中生长出来的。

先来看一张图：

这张图是 2018 年 8 月份我为团队制定的技术栈架构分工图，上面基本涵盖了 2018 ~ 2020 年团队所须要的的技术栈能力，它也会随着业务和团队不断的微调和修正，等到了 2019 年 8 月份我会从新梳理一个新版本，未来到这里分享给你们。

在带这个团队的一年多时间里，我对于团队的构想其实发生了不少次的变化，抽象的通用一点，一共会有两个并行的过程，一个是从人和团队视角的作好团队规划与管理，一个是结合业务针对团队作具体的技术栈的演进和架构路线调整，两个过程会交叉实施互相影响。这些方法和结论也有它特殊的公司背景和局限性，未必适用于你们所在业务形态下的团队，千万不要硬搬，能够关注下这些过程当中的变化，以及个人思考过程，最终咱们再回到上面的这张图上，你们就能明白一个团队的技术栈架构和演进背后的方法论了。

1、团队管理

首先说团队管理，这个是前提，没有配套的团队管理手段辅助，是很难单纯的让技术栈发生持续的好的变化，也很难将架构理念推动落地的，在团队管理这里我主要是分红四步走。

第一步 了解团队的长与短

新加入到一个团队，尤为是成为资深工程师后新带领一个团队，除了埋头作事外，有一个很重要的事情要尽早作，那就是去了解团队，方式有不少，好比：

• 主动去看团队仓库里的历史代码，了解你们的编码水平，编程风格，工程维护的方式，架构的成熟度
• 与每一个同窗单独聊聊天，聊聊他对于一个技术的见解，对于业务上思考，对于本身和所处团队的认知
• 请你们去吃吃饭，听听你们都聊什么，玩什么，关注什么，每一个人的气场和表达方式，在办公桌和餐桌上有什么不一样
• 找服务端团队和业务团队的同窗，问问他们对于前端团队的印象，对于合做童鞋的见解
• 在会议上抛出一些问题，观察你们的参与积极性和表述观点的深度

还能够一块儿去打游戏看电影，一块儿参加公司活动等等，这是一个比较粗的了解，我进团队后，也是挑了上面两三种方式对团队成员有了一个比较粗的摸底，看到了不少好的特征也看到了很多问题。

好的方面：都很年轻很聪明，学习能力较好，可塑性都很强，没什么城府，对技术有激情也有热情，技术栈很新颖，每一个人潜力都很大。

基于这些，能够预判这个团队只要理清楚每一个阶段的重点，就能够快速成长，每一个人都能不断的突破天花板，因此大盘子的性质不错，资质也不错，再来看看问题：

问题：职场的专业度不够，比较情绪化，对于业务多变有必定抵触，职业规划无感知，对于好的很差的评判标准比较狭隘比较封闭，总体工具化工程化以及基建的方向都没有太多思考，对于整个行业的判断比较粗浅，属于比较原始蛮荒的阶段，团队成员的能力层次不齐，补位与大局意识比较薄弱。

具体的方法论，能够把近几周的问题作汇总，而后给它们打标分类，好比这样：

结合业务和开发过程，来梳理问题共性，最终的问题能够总结为：

• 人心不稳定
• 技能短板多
• 职业无规划
• 合做意识差
• 团队无规范
• 工具基建弱
• 业务无感知
• 梯队未搭建

基于这些，能够预判团队须要一个不短的磨合期，在磨合期中须要先逐步创建信任，同时针对不一样的问题须要学唐僧跟你们常常讲多讲，也就是经过灌输让你们先有一个正确作事的概念在脑海中，而后再针对每个同窗的特征，以不一样的方式分配任务，驱动和辅导，另外，须要有一些事情你们要一块儿作来造成团队协力和凝聚力，我最终选择了技术分享做为一个你们共同作的事情，让团队在这一件事情达成惟一的共识 - 技术团队影响力的提高和我的总结能力的提升。

第二步 鞭策团队完善内部短板

所谓内部短板，就是彻底是本身的锅的问题，好比发布系统不完善，好比代码不规范，好比工具不健全这些都是甩都别想甩出去的锅，有了第一步的总结概括后，就能够在这些问题里面，优先挑选跟业务有强关系的问题重点突破。

我当时选择的是开发的上线流，也就是从开发到发布这个开发团队必须具有的刚需能力，从这条线劈出来各类工具和系统，童鞋们的反对声音会相对低，并且因为系统的效率和稳定性能带来更多的资源释放，也能带来参与同窗的极大成长，因此经过规范和工程的方式来弥补内部短板，是一个很是可取的团队管理手段，见下图，是从 2017 年下半年以后到 2018 年，在开发上线流程上发生的变化：

这一路的基建过程大概陆续进行了半年多，基本团队里最人肉最脏最累的活儿，都由机器作掉了，虽然跟业务没有直接关系，但它间接保障了业务的可持续性和稳定性，同时一路升级打怪，也让参与开发的小伙伴们都有较大的编程和工程能力提高，成为最先的一批技术骨干。

第三步 推进团队迈向无主之地

若是已经解决掉了团队的核心内部问题，接下来就能够把跟产品，运营、业务有关系的环节完善掉了，好比 App 在线上运行的异常监控这些，实际上在创业公司，通常是没有一个部门直接对它负责的，你们都焦点在业务上，那么这时候从前端团队手里出去的做品，理应由前端本身驱动本身来为它负责，这里我把线上运行时的监控单独做为一条线，它配合内部问题的 Mock 阶段的 GPM（GraphQL 数据聚合服务层），都是跨出了前端团队的职能，与其余团队产生了关系，见下图：

不只对业务，对于其余的中台部门好比人事、财务和行政都是同样，只要有精力，均可以尽量用成本最低的技术手段，来为公司内三无论的无主之地作一些协同的工具和系统，这会给团队带来不少正向的口碑，同时也有技术的提高，最重要的是，在内部问题和外部协同上，一旦你成为发起者和驱动者，你的角色和身份就发生了变化，你既是产品经理也是项目经理，既是需求方也是业务方，对于我的的综合能力会有很大的提高，对于整个团队在公司内部的影响力提高也有帮助，在工做中部门之间互相帮助也打下了一些底子，这一点对于不善表达比较木讷的工程师团队颇有意义。

第四步 鼓励团队技术与业务创新

从前面的三步，你们能够看出个人套路，带团队往前走，比较稳的方式就是从内到外，从技术到跨团队事务到业务，最终也就是第四步，再回归到业务和技术的结合，来利用技术创新驱动业务，利用业务可能性倒逼技术突破，这虽然不是终极态，但对于工程师团队已是一个很是可接受的状态了。

差很少在 2018 年 5 月份开始，我开始 push 前端团队把一只脚迈进到业务中，不管是技术预研，仍是业务场景挖掘，咱们在作好业务支撑的同时，绞尽脑汁去思考，到底这么多这么酷的前端技术，怎么跟个人业务产生关系，怎么挖到产品经理挖不到的地方，另辟蹊径为业务创造可能性，那么在这一点上由于会触及公司的核心商业机密，我接下来就举一个早期的脱敏案例供你们感觉。

在咱们的移动生态都是 App 的时候，微信生态也在蓬勃生长，那么若是产品延展到了小程序，咱们将如何支撑，要知道此时全公司都没有任何一个业务包括产品有过相似的具体规划，但你们都有一些很虚的想法和概念丢进来，这时候工程师经过与业务方出差去用户现场，去评估有没有小程序落地的可能性，回来后咱们开始作小程序的技术预研，经过这个过程，咱们抢在业务和产品前面，作了必要的技术储备，从而为后来快速打开微信生态，进入小程序的新载体阵营打下了关键的技术基础。若是工程师在这时候没有主动进入业务的意识的话，也是彻底不可能让业务方有信息甚至有意愿来进入一个新的生态的，因此等到团队里的部分工程师都能成长出这种意识和能力的时候，我认为就是一个合适的时候，来作技术栈的长远规划了。

2、技术栈规划

在我带团队的前面 10 个月，其实我也尝试作过零碎的技术栈规划，但效果并不尽如人意，一个是客观基建基础不知足，很难作相对可靠可落地的规划，一个是团队成员的总体意识包括我的能力没有上来，这时候作有点适得其反，甚至会引发组员的抵触情绪，总结下就是必要的小的相对零碎的技术规划必定要有，但不建议垮大周期作大而全的，能够作 1 ~ 1.5 年左右的。

ReactJS - 第一次大规模应用技术栈归一

不管是 RN，仍是 PC 端的 ReactJS，小菜前端的 React 技术栈在头三年就实现归一了，只是归一而不规范，以及还有旧 App 是原生架构这样的历史包袱，但整体上到 2017 年下半年，React 技术栈外加 Webpack 是团队的标配了。

这条归一的技术栈结合后面的 NodeJS 能力，也就孵化了咱们的两个核心前端框架：

• 客户端 RN 框架 Brick
• PC ERP 单页框架 Highway

NodeJS - 第二次大规模技术栈锁定归一

咱们再回到 NodeJS，也就 2017 年初是初步使用，2017 年末是深度使用，从 2017 年末开始，NodeJS 就成为了团队的一个核心能力，经过它，咱们把 RN 的基建全家桶一条龙所有实现了，好比脚手架，组件化，代码校验，机器打包，支持白名单的热更新发布，包安装成功失败与跟踪，端用户访问行为数据可视化，端运行异常监控与指派等等，这一条龙让咱们有信心来把全部的 App 所有重构为固定的 RN 版本最新的路由，

除了支撑客户端基建，NodeJS 还为咱们打开了内部系统开发的一扇门 - 服务端能力，这扇门对于前端对于公司都是有极大好处的，从前端的角度，能够掌握更多技能能够支撑更多业务能够把技术玩的更 6，从公司的角度，在不大规模动用先后后端产品和运营的资源下，前端工程师能够独立完成跟业务相对不那么强耦合的业务，又省钱又省时间，是很是划算的投入产出比。

那么在 NodeJS 这个技术栈上，咱们长出了不少能力，为业务提供了大量帮助，对于团队而言，沉淀了一个核心的服务端框架：

• Node 服务端（基于 Egg）框架 Cross

之因此研发 Cross， 是由于咱们一路用 ExpressJS/KoaJS/ThinkJS 过来，框架的定制升级和集成咱们想要复用的功能都不够规范，也不够严谨，直到咱们使用 EggJS，基于它的强约定和插件机制能够方便的集成过来，来定制咱们本身的框架，咱们再 2018 年下半年开始启动这个框架的定制直到年末出炉。

GraphQL - 第三次小规模的技术栈尝试

GraphQL 必定会成为 2019 年相对高频的词汇出如今你们的视线里，咱们是从 2017 年开始使用，同时在 2018 年 4 月份直接研发了聚合数据服务系统，集成到了咱们的网关下面，为各个 App 端提供定制数据的能力，咱们尝到了不少甜头，也遇到了很多阻力和调整，在 2019 年咱们会持续的耕耘它，至少在特定的领域内大规模使用。

还有一些数据搜集、加工计算和可视化的一些组装层咱们是交给了 Python 和 C#，甚至是 Rust 的尝试，这些均可以看作是技术预研，还不能称为咱们的核心能力，因此暂时不做为核心技术栈的演进目标。

MPVue/Vue - 第四次大规模的小程序技术栈归一

若是说 GraphQL 是咱们遇到的一个惊喜的彩蛋，那么 Vue 则是一个让咱们惊讶的彩蛋，咱们本来的演进路线里并不包含它，但限于咱们业务的复杂度，和当时市面上可选择的局限性，咱们最终选择了 MPVue 做为咱们的小程序框架载体，那么也天然没有考虑京东的 Taro，那时候 Taro 还太青涩没法在生产环境用，虽然使用 MPVue 给咱们带来了不少可能性和效率，它也为咱们带来了困扰，那就是技术栈在团队内出现了必定程度的割裂，毕竟它跟 React 的语法和生态不一样，到目前为止，基于小程序的生态，咱们把 MPVue 做为核心的小程序技术栈，基于这样的一个端领域实现了归一。

那么整体全篇下来，会发现咱们的技术栈演进，是会随着团队人员能力基建成熟度，也就是必定的团队管理和成长而变化的，同时也会跟咱们的业务及生态有强关联性，除此以外，技术栈规划确实是一个看着很客观但实际上也比较主管的工做，它里面杂糅了不少的因素，这些因素在不一样时期的权重还不一样，当团队能力强的时候，能够规划的长远一些硬核一些，团队能力弱的时候就要灵活一些。

因而从 2018 年下半年开始，我开始作相对硬核的技术栈和架构规划，也就是有开篇的这张图：

一共是这十二个课题和方向：

• Node 服务，支撑工具、业务系统、运维、监控等
• 前端基础框架，支撑将来几十个甚至上百个 PC/H5 ERP/Saas 工具系统
• 先后端协同方案，支撑特定业务领域的数据聚合，下降开发成本
• 端行为数据监控，为业务/产品/运营提供产品设计及业务调整决策
• 端性能监控跟踪，为端可靠性稳定性提供保障
• 端数据计算中心，为可视化、图形图像及视频多媒体提供高性能计算服务
• 构建部署，为多端提供总体开发、测试、打包、发布部署提供运维能力
• 客户端逆向，为社群/CRM/人与人新的连接关系提供必要的技术底层方案
• 安全防控，为全端提供安全监测、警报、拦截等护航保障
• 平台组件化，为跨端提供低成本可复用的 UI 组件及将来的智能化拼装
• 交互研究，为交互体验、ABTest、用户行为价值、设计表达输出工具与方法论
• 端/数据报表透视与可视化，为全公司提供友好的可快速产出与维护的报表可视化方案

这些课题向下，再延展出各个技术栈的方向规划，就是当前团队内咱们开始并持续关注的事项了，接下来的技术栈也会顺着这些课题方向而不断的演进升级。

最后，业务支撑、技术价值、我的成长、组织升级这几者之间的确很难达到理想中的平衡的，但基于创造更多的业务价值这一核心立论，不断去寻找场景寻找突破点的这样的 action 是咱们做为管理者和技术骨干所要坚持到底，不管什么时候，这都是优秀的工程师和技术决策者的责任和宿命 - 为人负责，并为结果负责，借事修人，借人成事。

---

最最后，本文做为预热篇，旨在针对以下话题为你们输出：

• 把团队蛮荒到自动化运维的从 0 到 1
• 成长历程总结输出给社区，帮助更多的小团队少走弯路
• 以一种可被量化的方式汇聚小菜前端的困惑、沉淀与方法路径，给团队带来更多创做成就感
• 从更多视角侧切进入团队管理/技术演进/我的成长的过程当中，探讨工程师团队的价值最大化

若是你们感兴趣，咱们小菜前端团队，会集体智慧共同凝聚，一块儿撰写并推出一本偏前端职业生涯、技术成长和团队成长的小册，回馈给你们，你们在文后记得留言评论和提需求哦。

Scott 近两年不管是面试仍是线下线上的技术分享，遇到许许多多前端同窗，因为团队缘由，我的缘由，职业成长，技术方向，甚至家庭等等缘由，在理想国与现实之间，在放弃与坚守之间，摇摆不停，心酸硬扛，你们能够找我聊聊南聊聊北，对工程师的宿命有更多的了解，有更多的看见与听见，Scott 微信： codingdreamer，也能够来关注 Scott 语雀跟进最新动态，本文未经许可不准转载，得到许可请联系 Scott，不然在公众号上直接转载，尤为是裁剪内容后转载，我都会直接进行投诉处理。