前端小团队如何搞基础设施建设？

前言

我为何会思考这个问题？这得从一篇演讲稿提及：

上文最初大概是在2020年四、5月份的时候看到的（当时仍是在语雀上，不过如今连接已经失效，好在知乎上面还找获得），做者在上述演讲稿中详尽地介绍了其团队在一年多的时间内如何从零到一构建了庞大的前端基础设施体系，以及这些基础设施到底起到了多大的做用；整篇演讲稿看完真是使人恍然大悟，原来前端能够如此高效以及成体系，看完后我真是对该团队拥有的前端基础设施垂涎三尺，而后臆想了一下在如此高效的前端体系中工做应该是一件很幸福的事情。

不过，考虑到文中这种庞大的、成熟的前端基础设施是创建在庞大的前端团队以及超多的前端业务场景的积累下建设而成的，那么小团队怎么办？

因而很天然地我就想到了这个问题，也在一直试图寻找这个问题的答案；在通过2020年内大半年的在团队内部的基建实践（比较初级）后，我想也许是时候回答和整理这个问题的思路了。

小团队的现实问题

考虑到现实，毕竟大多数前端团队不像大厂那样有丰富的团队人员配置，大多数仍是很小的团队，小团队在实施基建时就不可避免的遇到很现实的阻力：

• 最大的阻力应该就是受限于团队规模小，没法投入较多精力处理做用于直接业务之外的事情
• 其次应该是团队内部对于基建的必要性和积极性认识不够（够用就行的思想）

小团队基建的必要性

综合上面的现实问题，是否就能够认为前端基建就是大厂/大团队的专属权利和义务呢？毕竟看起来有点没法下手和吃力不讨好的样子；

在我看来，所谓的基建就是一切能够提高编码效率、团队协做效率及业务鲁棒性的工具和方法的集合；只要是项目还在迭代、扩展，就不可避免地遇到新的问题以及效率瓶颈，更不用说不少项目内的业务痛点；目前不少的项目内问题解决路径就是：直到问题出现才会去解决问题（甚至是到问题严重的时候才会去解决问题）；

这就是基建最核心的价值：帮助业务更好的活在将来。1

我很认同上面这句话，基建不只能够帮助提高当下的效率，还能够避免一些问题的出现，以便业务更好地可持续发展；

小团队应该建设哪些基础设施？

考虑到基建的必要性和小团队的现实问题，我给出的答案是：

• 优先级：优先发展投入产出比大的地方
• 范围：着眼于自身业务沉淀及业务需求
• 自动化程度：量力而行，不要一开始就追求大团队所拥有的成体系的自动化前端基建，推荐“局部研发链路的自动化”

在设计工具的相关交流中，咱们还发现了有的团队开始把交互相关的功能也作了进去，例如将页面跳转，后端处理流程逻辑等进行了可视化编辑，自动生成相应的接口和流程代码。这种探索能够归纳成：“局部研发链路的自动化”。它是一个初期提效颇有用的方法。在对外交流中咱们发现了两点有用的建议：

一是任何团队均可以而且也都应该作，没必要以为本身团队研发实力不够，等大公司推出相应方案。局部自动化的关键其实对本身的业务和人员分工的一种总结和思考。在技术上，当本身的业务相对肯定时，经过一些简单的方法就能实现。而大公司要考虑的大而全，不必定适合。在人员组织上，几乎全部的自动化方案都有必定的分工要求，这也是因组织而异的。局部的自动化是以后总体架构变革的关键前提。2

投入产出比较大的地方

• 规范文档：我的以为规范文档应当是整个基建中的灵魂，由于规范文档能够看作是整个团队的共识，在没有共识的状况下开展基建难免会遇到不少不理解的地方；并且制订相应的规范能够先参考业界经常使用的，而后再具体讨论内部的细节，花费的时间不须要太多，可是带来的收益绝对是极大的（有效地提高团队协做共识和效率）；
• 业务（通用）组件：前端项目随着业务扩展，就会天然地抽象出能够被复用的业务组件，这也是一种业务沉淀；不过我的以为组件的产出流程应该归入基建中，加以规范和流程化，不然容易形成组件复用率不高、扩展性不强，耦合度太高等问题；
• 工具函数：实际上跟业务组件相似，只是组件在前端项目内偏向于视图层，而工具函数就是逻辑层，一样地工具函数的产出流程也应当规范化；
• 代码检测：这个其实是配合代码规范文档进行的一种辅助手段，由于口说无凭，规范毕竟不是一种实体性质的东西，实际编码过程当中可能出现不遵照和遗忘代码规范的状况，若是缺少一种强制手段来检测规范的执行，那么代码相关的规范约束力就会大打折扣；事实上，现在社区已经存在各类相应成熟的代码检测工具，只须要根据内部约定的规范作一些修改配置就够了；
• 脚手架：当公司业务项目之间出现高度的类似时，则能够利用脚手架将以前沉淀的项目配置规范化，完成项目建立流程的规范化，能够知足项目快速建立的目的，且项目初始化工做显著减小还能够复用已经沉淀的一些项目配置；

基建实践

说了这么多，那么如何在项目中实施前端基建呢？这里以我在内部的某个项目实践为例：

• 项目背景：APP配套使用的业务后台；前期工做是从老项目中迁移（重构），后期加入各类新增模块；
• 项目特色：模块繁多，某些模块功能类似度很高，表单复杂度较大；

上图就是我在项目中大概作的一些基建相关实践的概况；

公共组件产出流程

渲染模型/DSL

其余

• 解决多分支并行开发公共文件维护的几种方案 | snowdream

基建的效果

• 团队协做效率提高，规范性明显加强
• 经过前期组件/公共的积累和沉淀，后续开发速度明显提高（搭积木式开发）
• 代码复用率明显提升，减小复制粘贴次数

后话

尝试基建能够收获不少

在项目中积极实践/推动基建后我才发现，原来尝试基建能够收获到不少东西：

• 对前端项目总体会有更深、更本质的认识，可以找出更多的业务及编码痛点
• 能够拓展提效的更多思路，接触到更多高效的编码体系及工具
• 能够增强全局观念，认识到各类架构、解决方案的具体适用场景，而后尝试提出更适用于具体业务场景下的架构及解决方案

简言之，积极尝试基建不只能够对当下项目提效，还能提高自我解决问题的能力；在这不到一年的实践中脑海里已经闪出了各类各样的解决方案，有的是已经应用了，更多的则是还在探索和检验中，总之收获了不少灵感：

• 
  

基建没有终点

我我的以为只要是项目还在发展/迭代，基建就没有终点；这一点从大厂的实践来看也是同样的，大厂们正齐步从可视化搭建（半自动化）迈向智能化搭建（全自动化）的探索之路；