前言
兄弟们可能有的感受
-
感受一:入职 初创公司 或者成立 新的团队 而只有你一个前端,不知道从何做起。
-
感受二:天天写业务代码和内部工具,感觉没技术沉淀,成长太慢,然后发现架构那边挺有趣的。
-
感受三:对一些框架的原理、源码、工具 研究较少,无法突破评级,成为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规范钩子,页面适配,权限,本地存储管理等等,来减少开发新项目时前期准备工作时间,也能更好的统一公司整体的代码规范。
-
通用后台管理系统基础模版封装
-
通用小程序基础模版封装
-
通用h5端基础模版封装
-
通用node端基础模版封装
-
其他类型的项目默认模版封装,减少重复工作。
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