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

发表于 2021-01-09 分类于探索

前言

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

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

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

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

小团队的现实问题

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

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

小团队基建的必要性

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

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

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

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

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

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

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

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

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

投入产出比较大的地方

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