小菜前端的技术栈是如何规划和演进的。转。作者 Scott。
一、团队管理
首先说团队管理，这个是前提，没有配套的团队管理手段辅助，是很难单纯的让技术栈发生持续的好的变化，也很难将架构理念推进落地的，在团队管理这里我主要是分成四步走。
第一步 了解团队的长与短
新加入到一个团队，尤其是成为资深工程师后新带领一个团队，除了埋头做事外，有一个很重要的事情要尽早做，那就是去了解团队，方式有很多，比如：
- 主动去看团队仓库里的历史代码，了解大家的编码水平，编程风格，工程维护的方式，架构的成熟度
- 与每个同学单独聊聊天，聊聊他对于一个技术的看法，对于业务上思考，对于自己和所处团队的认知
- 请大家去吃吃饭，听听大家都聊什么，玩什么，关注什么，每个人的气场和表达方式，在办公桌和餐桌上有什么不同
- 找服务端团队和业务团队的同学，问问他们对于前端团队的印象，对于合作童鞋的看法
- 在会议上抛出一些问题，观察大家的参与积极性和表述观点的深度
还可以一起去打游戏看电影，一起参加公司活动等等，这是一个比较粗的了解，我进团队后，也是挑了上面两三种方式对团队成员有了一个比较粗的摸底，看到了很多好的特征也看到了不少问题。
技术分享作为一个大家共同做的事情，让团队在这一件事情达成唯一的共识 - 技术团队影响力的提升和个人总结能力的提高。
第二步 鞭策团队完善内部短板
所谓内部短板，就是完全是自己的锅的问题，比如发布系统不完善，比如代码不规范，比如工具不健全这些都是甩都别想甩出去的锅，有了第一步的总结归纳后，就可以在这些问题里面，优先挑选跟业务有强关系的问题重点突破。
开发上线流：工程骨架 -> 组件安装 -> Mock -> 代码校验 -> 打包测试 -> 打包线上 -> 推包 -> 配置白名单 -> 审核发布
第三步 推动团队迈向无主之地
如果已经解决掉了团队的核心内部问题，接下来就可以把跟产品，运营、业务有关系的环节完善掉了，比如 App 在线上运行的异常监控这些，实际上在创业公司，一般是没有一个部门直接对它负责的，大家都焦点在业务上，那么这时候从前端团队手里出去的作品，理应由前端自己驱动自己来为它负责，这里我把线上运行时的监控单独作为一条线，它配合内部问题的 Mock 阶段的 GPM（GraphQL 数据聚合服务层），都是跨出了前端团队的职能，与其他团队产生了关系
为公司内三不管的无主之地做一些协同的工具和系统，这会给团队带来很多正向的口碑，同时也有技术的提升，最重要的是，在内部问题和外部协同上，一旦你成为发起者和驱动者，你的角色和身份就发生了变化，你既是产品经理也是项目经理，既是需求方也是业务方，对于个人的综合能力会有很大的提升，对于整个团队在公司内部的影响力提升也有帮助，在工作中部门之间互相帮助也打下了一些底子，这一点对于不善表达比较木讷的工程师团队很有意义。
第四步 鼓励团队技术与业务创新
从前面的三步，大家可以看出我的套路，带团队往前走，比较稳的方式就是从内到外，从技术到跨团队事务到业务，最终也就是第四步，再回归到业务和技术的结合，来利用技术创新驱动业务，利用业务可能性倒逼技术突破，这虽然不是终极态，但对于工程师团队已经是一个非常可接受的状态了。
二、技术栈规划
ReactJS
VueJS
NodeJS
