前端基建有哪些？大小公司偏重啥？

前言 

兄弟们可能有的感受

  • 感受一：入职 初创公司 或者成立 新的团队 而只有你一个前端，不知道从何做起。

  • 感受二：天天写业务代码和内部工具，感觉没技术沉淀，成长太慢，然后发现架构那边挺有趣的。

  • 感受三：对一些框架的原理、源码、工具 研究较少，无法突破评级，成为leader。

上面的感受都是一些兄弟们的典型感受（也包括我自己）。这时候不妨可以考虑一下，了解了解前端的基础建设，进而 搭建起一个坚实的底座和让自己得到一个提升

正文开始——关于“基建” 

1.什么是基建？

  • “技术基建”，就是研发团队的技术基础设施建设，一个团队通用技术能力的沉淀。

  • 小到文档规范，脚手架工具，大到工程化、各个领域工具链，凡是能促进业务效率、沟通成本都可以称作基建。

  • 网上看到的一句话，说的很好， “业务支撑是活在当下，技术基建是活好未来” 。

2.基建的意义

主要是为了以下几点：

  • 业务复用，提高效率： 基建可以提高单个人的工作产出和工作效率，可以从代码层面解决一些普遍性和常用性的业务问题

  • 规范、优化流程制度： 优异的流程制度必将带来正面的、积极的、有实效的业务支撑。

  • 更好面对未来业务发展： ，像建房子一样，好的地基可以建出万丈高楼。

  • 影响力建设、开源建设：建设结果对于业务的促进，更容易获得内部合作方的认可；沉淀下来的好的经验，可以对外输出分享，也是对影响力的有力帮助。

基建搞什么 

1.核心：

下手之前首先得记住总结出的核心概念：

  • 三个落地要素： 公司的团队规模、公司的业务、团队水平。

  • 四大基础特性： 技术的健全性、基建的稳定性、研发的效率性、业务的体验性

根据结合落地和基础特性，来搭建不同"重量"和"复杂度"的基建系统。（毕竟每个公司的情况都不同）

2.方向

基建开始之前，首先得确定建设的策略及步骤，主要是从 拆解研发流程 入手的：

一个基本的研发流程闭环一般是：需求导入 => 需求拆解 => 技术方案制定 => 本地编码 => 联调 => 自测优化 => 提测修复 Bug => 打包 => 部署 => 数据收集&分析复盘 => 迭代优化 。

在研发流程闭环中每一个环节的阻塞点越少，研发效率就越高。基建，就是从这些耽误研发时间的阻塞点入手，按照普遍性 + 高频的优先级标准，挨个突破。

3.搞什么

通用的公式是： 标准化 + 规范化 + 工具化 + 自动化 ，能力完备后可以进一步提升到平台化 + 产品化。在方向上，主要是从下面的 8 个主要方向进行归类和建设，供大家参考：

  • 开发规范：这一部分沉淀的是团队的标准化共识，标准化是团队有效协作的必备前提。

  • 研发流程： 标准化流程直接影响上下游的协作分工和效率，优秀的流程能带来更专业的协作。

  • 工程管理： 面向应用全生命周期的低成本管控，从应用的创建到本地环境配置到低代码搭建到打包部署。

  • 性能体验： 自动化工具化的方式发现页面性能瓶颈，提供优化建议。

  • 安全防控： 三方包依赖安全、代码合规性检查、安全风险检测等防控机制。

  • 统计监控： 埋点方案、数据采集、数据分析、线上异常监控等。

  • 质量保障： 自测 CheckList、单测、UI 自动化测试、链路自动化测试等。

如上是一般性前端基建的主要方向和分区，不论是 PC 端还是移动端，这些都是基础的建设点。业务阶段、团队能力的差异，体现在基建上，在于产出的完整性、颗粒度、深入度和自动化的覆盖范围。

4.大小公司基建重点

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

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

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

大小公司基建重点：

  • 小公司： 针对一些小团队或者说偏初创期的团队，其建设，往往越偏向于基础的技术收益，如脚手架、组件库、打包部署工具等；优先级应该排好，推荐初创公司和小团队成立优先搭建好：规范文档、统一开发环境技术栈/方法/工具、项目模板、CI/CD流程 ，把基础的闭环优先搭建起来。

  • 大公司： 越是成熟的业务和成熟沉淀的团队，其建设会越偏向于获取更多的业务收益，如直接服务于业务的系统，技术提效的同时更能直接带来业务收益。搭建起一套坚实的项目底座，能够更好的支持上层建筑的发展，同时也能够提升团队的成长，打开在业界的知名度，获取更好的信任支持。大公司在基础建设上，会更加考虑数据一些监控以及数据的埋点分析和统计，更加的偏重于数据的安全防范，做到质量保证。对于这点，很多前端需要写许多的测试case，有些人感觉很折磨，哈哈哈哈哈哈。

下面，会针对一些大家都感兴趣的方向，结合自身过去部分的建设产出和一些文章的记录的整合（部分地方可能比较久远的，有些不记得出处。如有冒犯，深感抱歉，可与我联系！），为大家列举一些前端基建类的沉淀，以供参考。

基建怎么搞 

1. 规范&文档

规范和文档是最应该先行的，规范意味着标准，是团队的共识，是沟通协作的基础。

文档：

  • 新人文档（公司、业务、团队、流程等）

  • 技术文档、

  • 业务文档、

  • 项目文档（旧的、新的）

  • 计划文档（月度、季度、年度）

  • 技术分享交流会文档

规范：

  • 项目目录规范：比如api，组件，页面，路由，hooks，store等

  • 代码书写规范：组件结构、接口（定义好参数类型和响应数据类型）、事件、工具约束代码规范、代码规范、git提交规范

2. 脚手架

开发和维护一个通用的脚手架工具，可以帮助团队快速初始化项目结构、配置构建工具、集成常用的开发依赖等。

省事的可能直接拥抱框架选型对应的全家桶，如 Vue 全家桶，或者用 Webpack 撸一个脚手架。能力多一些的会再为脚手架提供一些插件服务，如 Lint 或者 Mock。从简单的一个本地脚手架，到复杂的一个工程化套件系统。

3. 组件

公司项目多了会有很多公共的组件，可以抽离出来，方便自身和其他项目复用，一般可以分为以下几种组件：

  • UI组件：antd、element、vant、uview...

  • 业务组件：表单、表格、搜索...

  • 功能组件：上拉刷新，滚动到底部加载更多，虚拟滚动，拖拽排序，图片懒加载..

4. 工具 / 函数库

前端工具库，如 axios、lodash、Day.js、moment.js、big.js 等等（太多太多，记不得了）

常见的 方法 / API封装：query参数解析、device设备解析、环境区分、localStorage封装、Day日期格式封装、Thousands千分位格式化、防抖、节流、数组去重、数组扁平化、排序、判断类型等常用的方法和hooks抽离出来组成函数库，方便在各个项目中使用

5. 模板

可以提前根据公司的业务需求，封装出各个端对应通用开发模版，封装好项目目录结构，接口请求，状态管理，代码规范，git规范钩子，页面适配，权限，本地存储管理等等，来减少开发新项目时前期准备工作时间，也能更好的统一公司整体的代码规范。

  1. 通用后台管理系统基础模版封装

  2. 通用小程序基础模版封装

  3. 通用h5端基础模版封装

  4. 通用node端基础模版封装

  5. 其他类型的项目默认模版封装，减少重复工作。

6. API管理 / BFF

推荐直接使用axios封装或fetch，项目中基于次做二次封装，只关注和项目有关的逻辑，不关注请求的实现逻辑。在请求异常的时候不返回 Promise.reject() ，而是返回一个对象，只是code改为异常状态的 code，这样在页面中使用时，不用用 try/catch 包裹，只用 if 判断 code 是否正确就可以。再在规定的目录结构、固定的格式导出和导入。

BFF（Backends For Frontends）主要将后端复杂的微服务，聚合成对各种不同用户端（无线/Web/H5/第三方等）友好和统一的API；

7. CI/CD 构建部署

前端具备自己的构建部署系统，便于专业化方面更好的流程控制。很多公司目前，都实现了云打包、云检测和自动化部署，每次 git commit 代码后，都会自动的为你部署项目至 测试环境、预生产环境、生产环境，不用你每次手动的去打包后 cv 到多个服务器和环境。开发新的独立系统之初，也会希望能实现一种 Flow 的流式机制，以便实现代码的合规性静态检测能力。如果可以的话，可以去实现了一套插件化机制，可以按需配置不同的检测项，如某检测项检测不通过，最终会阻塞发布流程。

8. 数据埋点与分析

前端团队可以做的是 Web 数据埋点收集和数据分析、可视化相关的全系统建设。可实现埋点规范、埋点 SDK、数据收集及分析、PV/UV、链路分析、转化分析、用户画像、可视化热图、坑位粒度数据透出等数据化能力，下面给大家细分一些这些数据：

  • 行为数据：时间、地点、人物、交互、交互的内容；

  • 质量数据：浏览器加载情况、错误异常等；

  • 环境数据：浏览器相关的元数据以及地理、运营商等；

  • 运营数据：PV、UV、转化率、留存率（很直观的数据）；

9.微前端

将您的大型前端应用拆分为多个小型前端应用，这样每个小型前端应用都有自己的仓库，可以专注于单一的某个功能；也可再聚合成有各个应用组成的一个平台，而各个应用使用的技术栈可以不同，也就是可以将不同技术栈的项目给整合到一块。这点就很不错，在如今电子办公化如此细致的时代，可能许多公司工作中都不止一个平台，平台之间的切换十分的繁琐，这时候平台之间聚合的趋势想来是必然的。（个人浅显的理解）

目前成熟一点的框架有蛮多的，使用的底层思想也各有不同，目前我也在学习qiankun等框架中，期待后面能够给大家分享一篇文章，加油??

基建之外思考 

1. 从当下业务场景出发

很多时候我们的建设推不下去，往往不是因为人力的问题，而是 没想清楚/没有方向 。对于研发同学，我们更应该着重于当下，从方案出发找实际场景的问题，也就是从我们项目和团队目前的业务问题、人员问题，一步步出发。还有就是，我们得开这个头。没有一个作家是看小说看成的，同理技术专家也不会是通过看技术书籍养成的。在实践中也就是实际场景中学习，从来都是最快的方式。许多有价值的事从来都是从业务本身的问题出发。到头来你会发现：问题就是机会，问题就是长萝卜的坑。

2.基建讲究循序渐进

业界大部分的研发团队，都不是阿里、腾讯、头条这样基础完备沉淀丰富的情况，起步期和快速爬坡期居多，建设滞后。体现在基建上，可能往往只有一个基于 Webpack 搞搞的脚手架，和一个第三方开源的 UI 组件库上封装下自己的业务组件库，除此之外无他。如果兄弟们现在恰好是我说的这种情况，不用焦虑，很多前端也是一样的情况。只要我们一步步建设，慢慢落地基础设施，就一定会取得好的反馈。

3. 技术的价值，在于解决业务问题，并且匹配

技术的价值，在于解决业务问题；人的身价，在于解决问题的能力。

基建的内容我认为首先是 和业务阶段相匹配 的。不同团队服务的业务阶段不同，基建的内容和广深度也会不同。高下之分不在于多寡，而在于对业务的理解和支持程度。

“业务支撑” 和 “基础建设” 都是同一件事的两个面，这个 “同一件事”，就是帮助业务解决问题。任何脱离解决实际场景而发起的基建，都需要重新审视甚至不应被鼓励。如果时间成本没有那么多的话，建议先搭建好基本的建设底座，想要更好的闭环的想法还是先搁置一下。
作者-KAIHUA