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

我为什么会思考这个问题？这得从一篇演讲稿说起：

前端搞基建|堂主 - 如何推动前端团队的基础设施建设 - 知乎
https://zhuanlan.zhihu.com/p/148210793

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

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

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

小团队的现实问题

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

• 最大的阻力应该就是受限于团队规模小，无法投入较多精力处理作用于直接业务以外的事情

• 其次应该是团队内部对于基建的必要性和积极性认识不够（够用就行的思想）

小团队基建的必要性

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

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

这就是基建最核心的价值：帮助业务更好的活在未来。[参考链接1]

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

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

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

• 优先级：优先发展投入产出比大的地方

• 范围：着眼于自身业务沉淀及业务需求

• 自动化程度：量力而行，不要一开始就追求大团队所拥有的成体系的自动化前端基建，推荐“局部研发链路的自动化”

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

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

投入产出比较大的地方

• 规范文档：个人觉得规范文档应当是整个基建中的灵魂，因为规范文档可以看做是整个团队的共识，在没有共识的情况下开展基建不免会遇到很多不理解的地方；而且制订相应的规范可以先参考业界常用的，然后再具体讨论内部的细节，花费的时间不需要太多，但是带来的收益绝对是极大的（有效地提升团队协作共识和效率）；

• 业务（通用）组件：前端项目随着业务扩展，就会自然地抽象出可以被复用的业务组件，这也是一种业务沉淀；不过个人觉得组件的产出流程应该纳入基建中，加以规范和流程化，否则容易造成组件复用率不高、扩展性不强，耦合度过高等问题；

• 工具函数：实际上跟业务组件类似，只是组件在前端项目内偏向于视图层，而工具函数就是逻辑层，同样地工具函数的产出流程也应当规范化；

• 代码检测：这个实际上是配合代码规范文档进行的一种辅助手段，因为口说无凭，规范毕竟不是一种实体性质的东西，实际编码过程中可能出现不遵守和遗忘代码规范的情况，如果缺乏一种强制手段来检测规范的执行，那么代码相关的规范约束力就会大打折扣；事实上，如今社区已经存在各种相应成熟的代码检测工具，只需要根据内部约定的规范做一些修改配置就够了；

• 脚手架：当公司业务项目之间出现高度的相似时，则可以利用脚手架将之前沉淀的项目配置规范化，完成项目创建流程的规范化，可以满足项目快速创建的目的，且项目初始化工作显著减少还可以复用已经沉淀的一些项目配置；

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

• 项目背景：APP配套使用的业务后台；前期工作是从老项目中迁移（重构），后期加入各种新增模块；

• 项目特点：模块繁多，某些模块功能相似度很高，表单复杂度较大；

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

公共组件产出流程

渲染模型/DSL

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

基建的效果

• 团队协作效率提升，规范性明显增强

• 通过前期组件/公共的积累和沉淀，后续开发速度明显提升（搭积木式开发）

• 代码复用率明显提高，减少复制粘贴次数

尝试基建可以收获很多

在项目中积极实践/推进基建后我才发现，原来尝试基建可以收获到很多东西：

• 对前端项目整体会有更深、更本质的认识，能够找出更多的业务及编码痛点

• 可以拓展提效的更多思路，接触到更多高效的编码体系及工具

• 可以加强全局观念，认识到各种架构、解决方案的具体适用场景，然后尝试提出更适用于具体业务场景下的架构及解决方案

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

• 一个可行的全路由骨架屏生成方案

基建没有终点

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

1. 前端搞基建|堂主 - 如何推动前端团队的基础设施建设 · 语雀

   https://www.yuque.com/zaotalk/posts/glkg6d

2. 前端 DSL 实践指南（上）—— 内部 DSL - 知乎

   https://zhuanlan.zhihu.com/p/107947462

3. 如何从业务代码中提升技术：使用领域特定语言消除重复代码 - 知乎

   https://zhuanlan.zhihu.com/p/38532183

4. 前端搞基建|Scott - 如何在人单力薄时立项推动基建 · 语雀

   https://www.yuque.com/zaotalk/posts/oekk3r

5. 前端搞基建|堂主 - 如何推动前端团队的基础设施建设 - 知乎

   https://zhuanlan.zhihu.com/p/148210793

6. 长夜未央——企业级研发提效的下一阶段 - 知乎 

   https://zhuanlan.zhihu.com/p/66474056