笔者现在所在的公司之前前端技术栈就非常混乱，Vue、React和AngularJS三大框架都有, 而且风格相差也很大. 当时我就想收包裹走人. 关于技术栈不规范的下场可以参考印度的飞机: <为什么印度的飞机频繁被摔？>
很少有人能精通这三个框架的，更别说是一个团队。
三大框架跟编程语言一样都有自己的设计哲学，这跟库是不一样, 一个库的替换成本很低；而框架的背后是一个架构、一个生态。每个框架背后牵涉着开发思维、生态系统、配套工具、最佳实践、性能调优。要精通和熟练一个框架需要付出的成本是很高。
所以说团队的开发效率是基于稳定且熟练的技术栈的。稳定的技术栈规范有利于团队协作和沟通; 另外如果团队精通这个技术栈，当出现问题或者需要深入调优, 会相对轻松。
前端技术栈规范主要包含下面这些类型:

  • 编程语言 - Typescript或Javascript
  • UI框架及其配套生态, 以及备选方案。其背后的生态非常庞大:
    • UI框架
    • 路由
    • 状态管理
    • 组件库
    • 国际化
    • 动画
    • 服务端渲染
    • 脚手架、CLI工具
    • 组件测试
  • 样式. 包含了命名规范、预处理器、方法论等等
  • 动画引擎
  • QA. 包含了测试、Lint、格式化工具、监控
  • 项目构建工具流. 例如webpack、vue-cli
  • 包管理器。npm、yarn
  • 项目管理工具
  • 时间处理。例如Moment.js
  • 模板引擎
  • 开发工具
  • 后端开发框架
  • 工具库
  • 开发/调试工具

  • 等等



可以参考一下我们团队的技术栈规范
⬆️回到顶部

2.1 技术选型

如何从零对团队的技术栈进行规范, 或者说怎么进行选型呢？举个例子, 先确定备选项, 你现在要选Vue还是选React(一个可能引起论战的主题)？
恰好前几天在SegmentFault回答了一个问题: <什么时候用vue什么时候用react？>, 我讲了一个我们几年前是如何决定要使用React还是Vue的例子(注意结果不重要！)：
技术栈规范 - 图1
<谈谈技术选型的注意事项>这篇文章写得非常好，给了我一些启发。结合上面的回答的例子, 来讲一讲在对相关技术进行选型的一些方法(评分项):

  • 选择你最熟悉的技术。上面说到团队如果熟悉该技术，则可以很好地控制使用过程中的风险，方便对程序进行调优。所以成员熟悉、或至少Leader熟悉程度，是技术选型的一个打分项。我们团队最终选择React的一个原因，就是我们熟悉它，它已经在现有的几个应用中良好的运行了，所以 React + 1
  • 选择拥有强大生态和社区支撑的开源技术。有强大的生态和社区意味着，很多东西你不需要重复去造轮子，或者遇到问题可以很快解决，有更多的选择。从公司层面、使用活跃的技术也比较好招人。上面的例子也提到了这点，几年前React的生态是强于Vue的，所以 React + 1
  • 选择成长期的技术。<谈谈技术选型的注意事项>里面有一句话：’选择一个技术的最低标准是，技术的生命周期必须显著长于项目的生命周期’我们选择的技术应该是向前发展的、面向未来的, 这是选型的基本原则。所以我们一般不会去选择那些’过气’的技术，比如AngularJS(1.x)、Backbone. 因为现在有更好的选择，不必过于保守。‘向前’还意味着Leader要能够预判该技术未来走向，这里有很多参考因素，比如大厂的支撑、目前社区的活跃度、开发活跃度等等React、Vue都非常有动力，比如React最近的React Hook、还有未来的ConcurrentMode、Async Rendering… 在这点上Vue和React打成平手吧
  • API的稳定性。比较典型的例子就是Angular和Python，API不稳定会导致社区的割裂，也会导致项目升级成本变高、或者无法升级, 最终成为技术债。不过值得庆幸的是因为有这么多历史教训，现在开源项目在API变更上面是非常谨慎的，参考[译] Vue 最黑暗的一天事件.这点上React和Vue依旧打平
  • 基础设施配合。一个技术往往不是孤立存在的，它需要和其他技术相互配合，这种技术之间的融合度也是需要考虑的。这个根据团队使用情况来定，比如我们团队统一使用Typescript，Vue跟Typescript配合使用其实不理想，所以 React + 1
  • 业务考虑<谈谈技术选型的注意事项> 提到一点就是‘学会从业务端开始思考’. 意思就是选型需要充分地理解业务，理解用户需求，当下需要解决的首要问题，以及可能的风险有哪些，再将目标进行分解，进行具体的技术选型、模型设计、架构设计.一个典型的例子就是10年前火遍世界的Rails, 后端是使用Rails还是Java/C#/PHP这些传统后端技术? 很多初创公司(如Github、Gitlab、Twitter)选择了前者，他们需要快速开发原型、快速占领市场, Rails开发很爽很快啊, 这种选型就是符合‘业务需求的’。那么前端好像跟业务离得有点远? 随着‘大前端’的发展，我们的工作对公司业务的影响只会越来越大。比如上面提到的React Native，我们当时有考虑在移动端应用React Native技术，实现客户端的跨平台，这就是业务影响啊。这时候React是不是又要 +1? 同理还有什么服务端渲染、Serverless等等，期待前端的地位会越来越高

综上，在这个案例中，React是胜出的。
扩展:

⬆️回到顶部

2.2 迎接新技术

当然，对于团队而言也要鼓励学习新的技术、淘汰旧的技术栈。因为一般而言新的技术或解决方案，是为了更高的生产力而诞生的。当团队容纳一个新的技术选型需要考虑以下几点：

  • 学习成本。考虑团队成员的接纳能力。如果成本小于收获的利益，在团队里面推行估计阻力会比较大
  • 收益。是否能够解决当前的某些痛点
  • 考虑风险。一般我们不能将一个实验阶段的技术使用的生产环境中

就我们团队而言，每个成员都有自己感兴趣的方向和领域，所以我们可以分工合作，探索各自的领域，再将成果分享出来，如果靠谱的话则可以在实验项目中先试验一下，最后才推广到其他项目.

作者：荒山
链接：https://juejin.cn/post/6844903897610321934
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。