拿走这份前端研发流程图！
一、背景
最近研究了前端研发流程，总结了一份前端研发流程图，正好也到年底该总结了，于是认真研究了一番。
本人工作一年半，文章都是结合自己真实的经历写的，也欢迎大家探讨前端研发流程！
本篇文章讲整体的前端研发流程，主要讲整体，具体各个模块由于篇幅不展开
二、研发流程
1、开发前准备阶段
分为规范、文档两部分
（1）规范：
》编码规范
这一块涉及的就比较多&基础了，比如*lint规范、文件命名规范、工程结构规范、注释规范、图片处理规范等等
》技术选型规范
选这个技术栈是出于什么原因，能解决什么痛点？能给业务带来什么收益？举一个发生在身边的真实案例
反例一:大家都知道移动端组件库官网都有一个手机预览，如下图。手机预览的是一个组件示例项目，一个独立的H5项目。
实现方案是通过iframe实现（最近在封装一个taro-react组件库，也遇到了这个场景）
有一天，同事A兴奋的说：XX给我提了一个建议，咱们的文档可以通过`微前端qiankun`的形式实现，不用iframe了
我：？？
同事A：我觉得这个建议可行，说出去显得技术也厉害
总结：很明显这种技术选型存在问题的，首先iframe也是微前端的一种实现方案，选qiankun的动机单纯是为了“显的”技术厉害。
引入qiankun非但对该场景没有收益，还影响部署方式，代码结构等，反而显得“不懂技术”。
技术选型更体现一个人的技术功底，需要一定的技术广度，一定的技术深度，往往是高级前端需要必备技能
》架构设计规范：
架构设计就更有挑战了，是基于技术选型。讲究可维护性、可扩展性，对于复杂场景，具有创造性思维，创造解决方案；并能从业务中沉淀通用解决方案，造出轮子（工具、插件等），对于工具设计也有规范，保证易用性，帮助团队降本提效
一般的业务大家可能会觉得根本涉及不到架构设计啊，换个角度看，是你还不具备能看到需要架构设计的能力。架构师往往能一眼看到隐藏的问题，给出最佳实践方案
为什么有些人的代码写出来成了💩山，为什么有的人写出的代码像诗，差异巨大。往往跟整体的架构、系统设计有很大的关系，比如
- 网络请求模块封装的合理嘛
- 埋点通常接公司的埋点系统，直接拿来嵌在业务代码里面往往会污染业务代码
- 代码拆分合理嘛，有超多1000千的文件嘛，经常看到一个文件3、4千行，接手那叫一个酸爽
- 编译、打包的命令合理嘛，见过起一个服务居然必须要注入变量才行否则起不来
......众多的细节加起来，决定了工程架构是否优雅
》工时评估规范
这部分主要是项目管理 的需要了，每个人都有一套自己的工时评估规范，怎么保证评估模块A的2人天是准确的?
这方面我的经验就是：首先让负责开发的人自己评估，根据自己的一个实际情况评估一个时间；第二再check这个时间是否合理，是否忽略了某些相关的改动也需要工作量（PS：经历的大部分人都是评估出的时间过短，只看到了表面的功能，一开始没有把可优化、相关联的改动考虑进去，中途才发现时间来不及）
（2）文档
文档也是很重要一部分，相信我，没有一个人能记住业务流程、技术方案的！！ 在项目开始之前，就需要建立一个项目的文档，里面必须包括基本的PRD、UI稿、技术方案、以及必要的复盘
》PRD
- 通常在产品的文档空间，一般记录文档地址即可
- ⚠️开发时，总会发现PRD细节的小问题，最好提醒产品更新PRD，不然时间久了，回去看，没更新的问题坑的都是自己
- 对于有必要梳理的业务模块，需要结合技术整理偏业务的文档。举个🌰：小程序有很多分享，分布在PRD的各个页面上，十几个分享入口，参数是啥，回哪个页面，有些相同，有些不同，可以自己整理一个文档，更清晰明了
》UI设计稿
- 通常在设计空间，一般记录文档地址即可
》技术方案文档
- 架构设计
- 技术栈信息
- 重难点技术方案，比如登录、支付等 》复盘文档
- 开发时发现部分成员错误做法的踩坑文档
- 上线出现问题后的复盘文档
2、编码&联调阶段
这个阶段设计的就比较多了，也是大多数团队花时间最多的一部分
-
在确定技术方案时，首先需要确定基本的技术栈，这通常取决于团队用什么技术栈，比如我们C端用的是
Taro+React，B端用的是Vue；统一用Typescript、less -
选完基础技术栈后，通常会考虑选择物料库，最基本的物料库
组件+utils；组件一般来说业内开源的组件库能满足大部分，如Ant Design/Element/Vant，但是一般都会有业务相关的组件库，比如我们组内在做的C端多端组件库、B端业务组件库；pro的话意思是根据组内业务常用场景的代码模块，类似Ant Design Pro这种，都属于物料库 -
然后就是开始初始化工程了，到这一步用到
工程化的东西，最基本的用业内开源的脚手架实现工程搭建、开发服务、编译构建，如VueCli/create-react-app等；通常组内会有一个自己的轻量级的脚手架用来实现工程搭建，因为每个团队都有自己一套规范，但是通常很难会实现开发服务、编辑构建。所以我把这里写成了工程初始化命令行，用这个搭建工程，包括目录结构，选择的技术栈，，组件库，*Lint等 -
下一步就是根据PRD、UI稿开始
开发了；包括基础的业务代码编写，如果需要写单元测试的话还需要同时完成单元测试编写；以及数据方面的简单的本地mock和数据聚合；数据聚合的意思是前端做一层数据模型层，将几个后端接口合成一个，以根据组件需要的数据聚合接口 -
静态页面开发完成后开始练
联调环节，通常服务端需要给前端一个数据结构文档，code码文档；并且要求服务端接口需要保证都遵守这个规范。通常服务端开发前，需要给出接口文档，公司一般都有mock服务，前端先通过mock服务进行数据联调，避免阻塞开发
3、自测&优化阶段
很多人会忽略这个阶段，如果说开发联调完成后可以达到60分，那么这个部分是项目在基础上加分
-
埋点：这个没有写在开发阶段，因为这项，在编码上看，是在完成开发联调之后做的，在功能层面看，也是一个分析数据来做优化的 -
性能：在开发完成后，需要自测基本性能是否达标，比如图片体积是否过大，打包后的体积，依赖模块分析，浏览器兼容性，手机兼容性等等，这些都跟性能指标相关，需要一个标准 -
CR：提测前进行code review；需要关注，代码规范问题、单元测试是否达标，以及UI稿还原度，上一步性能标准是否达标 -
自测/修复：测试用例评审后测试通常会给一份冒烟用例，最基本的自测就是按照冒烟用例走一遍，看到业内还有一些有UI自动化测试等；都通过后进行代码合并到主分支。这里写了一个UI体验问题衡量标准的意思是，之前在碰到一个案例，C端商城订单列表的时间筛选，UI给了一个类似PC端的选择，手动选择开始时间、结束时间的年月日，当时我负责封装下拉菜单组件，同事找到我说，能不能把下拉菜单组件暴露XX事件（时间筛选是在下拉菜单里面）；当时我是觉得这个要求比较偏业务，然后觉得这个需求不合理，于是研究了下主站的订单筛选，张下面这样，在移动端还让人选择年月日的确不合理呀，于是乎让UI重新出稿
4、构建&部署阶段
这一步也是必备技能，现在公司一般都有自己搭建的一套自动构建发布流程，按照流程走就没啥问题。流量大的产品还需要考虑A/Btest、灰度发布；以及一些SaaS产品，PaaS产品需要考虑的私有化部署
5、上线后数据采集&分析阶段
上线后并不是万事大吉了，数据、监控、用户转化才决定着产品的真实情况
异常/性能监控：前端JS异常监控，JS执行错误是非常致命的，监控到错误后进行修改能给代码带来不少稳定性；前端性能通常是指首屏时间、网络请求时间等等指标，主要标识产品的体验性好不好。
之前写过两篇相关文章：指路别再用performance计算首屏时间了！！ ；面试必问：前端性能监控Performance
服务器监控：比如域名是否可访问，应用健康度，机器性能等，这部分主要看公司有无提供能力，团队想做一般很难告警：异常监控后会对应用负责人进行邮件或者APP告警异常处理：一般两种情况，出现线上紧急问题，切复现不出来问题，这时候就可以借用监控来寻找蛛丝马迹了，很紧急的问题，可能还需要有降级方案；第二种就是没有业务反馈问题，也需要日常去查看异常监控，可能小问题隐藏着大bug
写在最后
完整前端研发流程图如下，可以看到是一个闭环的
当然这是比较完整的流程，小需求、临时需求可能是这些流程的一部分
本文首发于GitHub，欢迎star～持续更新