前端开发流程的内容

作者：袖梨 2026-06-18

前端开发流程

我自己理解参考后的理解第一阶段: 需求产生-准备开发需求评审会拆分组建块建立分支第二阶段: 开始开发-提交测试单元测试单元测试覆盖率防御性编程第三阶段: 测试完毕-可发布状态编译包分析代码检查代码优化codereview 第四阶段: 准备发布 - 发布完成发布静态资源到CDN打tag修改线上版本号第五阶段: 发布上线 - 线上验证

我自己理解

2020-11-8 13:31 [30mins]
因为要打算去的实习公司呢,需要考到前端开发流程,所以就在这里充电一下,因为我自己对这方面的认识不是特别深,先简单说一下自己认识的一个程度,然后再去看下具体的一些掘金上面的案例, 我自己理解的部分你们可以看,也可以忽略.

因为我自己对前端开发流程虽然有做过类似的操作,但是我没有进一步的去总结,然后我自己的印象吧,因为我使用的是vue-cli脚手架搭建的项目,所以都会生成好整个工程架构,然后是项目架构的规范,这样其他团队成员看到项目的时候就可以知道哪些文件是放在哪里,或者通过路由自己去看.这两步做好之后就是接下来的业务开发我所理解的业务开发就是产品的需求和文档给的规定,接下来是联调及投产上线,前端尽量先去写好基本的页面布局, 然后马上给后端拿接口,所谓的联调就是拿接口.然后一个一个接口的渲染页面,这里比如一下我自己的一个经验吧. 比如我有一个轮播图在页面上是要显示的,那么我就先写好轮播图的一个组件,然后大概的数据格式也是心里有数,这样子. 然后就发请求给服务器,服务器在后端拿数据后响应回来我就可以去渲染了.但是这里会有一些算法的问题,如果后端处理的好的话,会做起来省心点,没有处理好就需要自己在前端的逻辑上去处理了.但是这一般都会帮你处理好.

总结一下: 工程架构 -> 项目架构 -> 业务开发 -> 联调及投产上线

我自己并不清楚这样是不是对的,但是大致的认识了一下,然后看的是掘金的一篇文章,这里就引用一下出处,感谢作者.后面还要阅读其他的文章来总结下,然后自己去实操下比较好,有时间当然是看下书或看看大牛的源代码了.下面蓝色字体是我引用的一个参考链接,有看到的小伙伴可以支持一下这位作者.

前端项目开发流程思考

我准备去吃个饭了,中午了,今天是在家里所以就自己做饭 2020-11-8 13:56 [25mins] 等下回来再看一篇前端流程自动化这篇会更加全面,反正多看点吧,闲着也是闲着哈哈哈, 突然想玩会,解除我滴烦恼,然后回来继续看前端流程自动化. …没想到一个下午过去了现在已经 2020-11-8 17:48 [30mins] 现在看下那篇文章吧,下次还是不要玩来,真的脑子这种东西克制都克制不住.

看了前端流程自动化这篇文章之后,我大概比刚刚看的那篇前端项目开发流程思考的文章会觉得这一篇是感觉是高手写的,但是高手嘛,解释起来可能内容解释起来就不太那么合适新手,所以我还是等下做完饭后再来总结一下我刚刚都认识了些什么.

2020-11-8 18:24 [36mins]
2020-11-9 00:13 [ < 10mins] 现在是晚上时间了,但是不是特别困,刚刚有点睡意,但是洗了衣服还没那么快转好,所以就来写一下自己今天看的这篇比较全面的前端流程自动化

从这篇文章前端流程自动化中,有个需求的会议要开,这个会议的作用就是说产品,开发人员需要去讨论,也许是在一个会议室里,然后讨论产品的需求是否满足客户方,然后技术人员是否可以开发此功能或者说是要修改一下换成类似的功能,还有技术选型,对于技术选型我的理解是使用什么语言来开发,使用什么便捷的工程架构来快速搭建,这样可以规范化开发和加快开发的速度.因为不可能说每个新手都去逐步的自己搭建,这样容易产生代码不统一,到时候处理起来会麻烦.需求会议弄好之后,应该就要规划该项目的功能的时间划比和每个任务归谁去管理,还有每个任务的优先级要排一下,那些需要先开发出来的. 接下来是开发分支和测试分支. feature 和master吧. 每个人这样就接到任务了,然后就可以开始开发了. 然后有个技术总监会监管每天会监管每个功能的进度,这样可以确保项目不会延期或者快速去解决某个功能的bug,以至于不会拖延到其他开发人员的工作进度. 基本上大家就是呆在一起了然后每天去完成任务了,这里有个非常重要的地方就是代码能够复制就复制,复制自己写好的变量命名或者是封装好的组件可以降低代码出错的可能性,然后提高开发效率.基本上就这样一个流程一直重复, 每个人commit完一天后就push到自己对应的分支上,不要提交到错的地方.所以这里对git的要有一定的理解.然后是代码的规范性,会有一些工具来检测代码的规范性,eslint的包吧可以做到,因为人为去做的话可能有时候往往发现不出来.最重要的一个环节是测试单元 ,测试单元非常重要是因为写好测试单元,能够更好的理解代码的组建进而使得实际的代码可以很熟悉,如果出现什么错误,修改的次数降低并且能够很清楚的知道哪里有问题. 都测试后之后就上线准备了,这里上线后要开始收集上线是否有什么问题要记录到日志中,然后集合起来的周报发送给上级去检查.知道最后整个项目正常运行了边维护边满足客户的其他需求来增强版本.这是我对这篇文章的一个理解了.

总结一下: 需求研讨会(技术选型,功能的需求分析,功能时间划比还有时间优先性划比); 测试单元; 线上维护和版本迭代.

参考后的理解

主要分为5个阶段,因为面试的公司上有这个要求所以要提前理解下最好.

第一阶段: 需求产生-准备开发

这的需求产生有3个小的阶段: 分别是需求评审会;拆分组建块;建立分支

需求评审会

需求评审会主要是需求产生->准备开发的一个阶段,作用是去分析需求是如何产生的,如果是敏捷开发(会根据客户的反馈来快速进行). 比如有一次我去面试对方给我出一道题关于js的,要我给他的公司会议做一个优化选择.这就是需求.然后知道逐个需求后就要安排每个需求完成的时间占比和优先性.进而每天对每个项目的跟踪和记录.

明白产品经历的真正意图,还有需求产生的背景
今天就先写到这里了, 要去晾下衣服然后也有点困意了. 晚安
2020-11-9 00:44 [30mins] 目前累计 [91mins] 明天起来继续把另外的几个阶段和理解写一下然后总结完就继续去优化简历了.
2020-11-9 12:07 [ < 10mins]

拆分组建块

前端需要划分模块, 这里所谓的模块其实我也不是说特别懂? (解决了) 这里需要充电一个知识点组件化和模块化有什么区别？我先点时间看完这个了, 现在我大体知道什么是组件化和模块化了,然后去吃个饭再回来继续

2020-11-9 12:19 [ 12mins]
吃了个中午饭,现在继续吧 2020-11-9 13:13 [ < 20mins] 因为组件化和模块化的知识点不是特别的熟悉,所以就去充电了一下我对组件化和模块化的理解 2020-11-9 13:49 [ 36mins].
继续回来说这一块 2020-11-9 16:44 [ < 30mins].

前端需要组件式开发,然后将页面进行拆分为足够细粒度的小组件和模块.由单独的人负责对应模块和组件开发,基本到了这个环节你就知道自己要做什么,做哪个部分了.

建立分支

许多公司都有自己的版本管理工具. git lab之类,具体就看公司对技术的统一选型. 然后每写一个新的功能就创建一个feature分支去写,写完之后合并到release分支等待测试和发布

第二阶段: 开始开发-提交测试

单元测试

单元测试就是: 不断的模拟一个实际开发的功能达到一定的覆盖率后去进一步转为实际开发的功能.这么做的目的是随着项目的扩大,降低项目复杂度的提升对你造成的困扰.

单元测试和写代码是有区别的. 单元测试是在写代码之前的, 比如你现在的需求是写一个可以切换的选项卡组件.如果你就开始写代码也就是直接在项目上写选项卡,这时候项目里面还有其他的代码,增加了你阅读代码的复杂度,此外再加上你对选项卡组件的理解又可能不是特别的熟练,那么就进一步的降低了你的代码开发效率,不止这样,随着整个项目的扩大,复杂度提升,那么你就越来越模糊.于是在写代码之前需要有足够的单元测试,而且单元测试的时间要大于写代码的时间,并且覆盖率要几乎接近写代码的部分.这么做就可以降低各种不必要的风险.维护起来也方便. 就像高手在写代码之前先写思路,然后根据自己的思路去写代码.而不是一开始去写代码,再举一个通俗易懂的例子就是别人叫你给你交代一件事情,说你去买瓶饮料,此时你接收到了一个任务就是去买瓶饮料,那么你在还没问清楚对方要的是什么饮料,就触动那么回来结果就知道了,因为饮料种类非常的多,这样对方肯定某种程度上会表现的不开心. 那么在这之前如果你问他说你要什么饮料,他说要瓶可乐,好,于是你去买瓶可乐,但是你发现你买的可乐是多糖的,他要的是低糖的,尴尬了. 下次的时候你问他要什么饮料,他说可乐,你说要什么牌子无糖还是,更加具体了,这样你就越来越能够理解他真正的意图了.所以这就是写代码和单元测试. 单元测试 > 写代码. 此外单元测试通常来自于测试人员整理的测试用例,所以你可以使用测试人员给的单元测试,这样的话你就不用自己去找些资料来弄了.当然单元测试就像面试题一样,你是要自己去想的.然后一步一步试错一步一步的尝试,记录和反馈,进而一步一步达到真正的意图.

这里需要补充两个东西, 函数式编程的出现,因为单元测试开始写会有点困难,但是函数式编程可以解决,后面需要充电什么是函数式编程.第二个东西是TDD的理念(先写测试用例) Test-Driven Development. 将具体实现放到后面，这样你就不会深陷细节的泥潭,先写好思路,理清楚思路了,觉得走得通了再去写代码,然后具体的代码api等再去查找或者是自己写.这个过程是需要时间去进步的,用心的编程人员每个月都会去迭代自己过去的一些代码,看看哪里可以写得更美.

单元测试覆盖率

那么单元测试覆盖率需要达到多少才算可以,业界是达到 95%以上才算合格.

防御性编程

理念: 假设每一行代码都会报错的防范意识去写

ts可以增加静态检测的功能,如果不使用,就需要自己去检验了.

如下代码所示,这是一种防御技巧

// String a -> Number b -> Booleanfunction testA(a, b) { if (!a) return false; if (!isString(a)) return false; if (!b) return false; if(!isNumber(b)) return false return !!a.concat(b);}