自我介绍下,四年工作经验,头两年全栈开发,后两年专职做前端,目前已达到高级前端工程师水平,经历过三家公司。第一家公司,电商行业,做阿里 ISV
供应商,为淘宝卖家服务,也是我第一次接触百万 UV
级别的产品,在第一家公司呆了两年,由于达到技术瓶颈期,遂跳槽,第二家公司,航运物流行业,呆了六个月(工作强度对我来说,是真的高),身体不适,没有同意转正。目前这家,担任项目管理和前端组长,两个角色,目前呆了两年,做了很多东西,把自己的一些想法跟大家聊一聊。
这是一家做保险和金融行业的公司,属于传统行业的科技公司,有点外包的性质,当然,也有自己的 SaaS
产品,由于是传统行业的公司,技术栈相对互联网公司来说,稍微落后一点。我刚来的时候,上一个前端要辞职了,然后做对接工作(告诉我,有啥问题,直接搜代码),我算是接盘侠,前任留下的屎山,其他的,大概有以下几点:
其中一个归 CTO(做后端) 管,另外两个在广东,我入职的时候,也没有确认,到底要不要带人。我来的时候,就已经在了,后面我领导跟我说,要带下他们,我当时压根就没有带人的想法,也是个坑。
Node
版本非常低,到现在还是 8.x
,各种低版本的库都在,比如 Ant Design
用的 3.6.2
,在项目开发中遇到穿梭框无法进行树状显示(代码一摸一样,在高版本 3.19.2
,可以显示)。又比如还有这种 "translate.js": "git+https://github.com/MichelSimonot/translate.js.git”
React
,Redux
使用,欠缺理解。有过一次”爆炸”,此项目如果再继续迭代下去,随时可能继续”爆炸”,现在已经是在踩雷开发阶段。
在 2019 年 10 月 18 号,24:00 发生生产事故,事故表现为,操作特定页面,浏览器崩溃,卡死。
脚本执行时间非常长,后面经查,是由以下代码引起
actions.getAgentListByPage({ companyId: currentAgent.companyId, pageIndex: 1, pageSize: 20000, searchProvince: currentAgent.province, searchCity: currentAgent.city })
页面很多地方存在请求 **_pageSize:20000_** 的情况,该代码是由前任前端编写,具体为何写出这样的代码,原因未知,处理方案给到后端解决,前端配合加入 `workbench` 字段,凌晨 1 点左右得到解决。
打包出来的项目代码体积有 49.5MB,页面首次加载耗时 11.4 min
基于以上的原因,向领导提出过重构,没有同意,我认为可能有两个方面的顾虑,
列举了以上的这些点,烂摊子太多了,好在有一个点,领导的支持力度还不错,看我是如何突围的。
前端技术建设的核心目的,是为了提高开发效率,保证开发质量,为保障项目高质量按时交付,同时兼顾考虑中长期研发实际情况,结合团队实际能力,为未来做技术储备,为业务发展提供更多的可能性,大概将自己的分为以下四类
首先,要对现有的问题进行梳理归纳,按照问题的优先级进行排序,然后,分阶段性目标进行实现,对于上面的问题,我大概整理了一张表格
问题 | 优先级 | 成本 | 目标 |
---|---|---|---|
如何打造前端工程化体系 | p0 | 高 | 提升整个前端团队的开发效率、按时交付、保证交付质量。 |
如何进行团队管理 | p0 | 中 | 进行人才储备,提高团队人员技术能力 |
如何进行项目管理 | p1 | 中 | 掌控全局,知道项目下的人都在做什么,资源协调 |
主要是指代码权限控制,目的是确保代码安全,问题可控可避免可追溯
具体管理举措有以下几条:
GitLab
,默认关闭所有外网访问权限,针对每个项目,按实际需要给开发赋予指定权限。PR
,然后在组长进行 CR
后,才能提交到主仓库。前后端开发联调有一个严重问题,就是后端接口变动或者字段改动时,没有在事前事后通知相应前端开发,测试人员,导致效率底下,并且会出现各种异常情况。
因此,通过梳理开发流程,出接口文档,作为对接标准。
我们使用 apiDoc
来作为前后端联调标准。
但在实际情况中,还是会有一些接口文档和实际接口不符的情况发生,导致一些问题产生,这个我们也在思考。
刚入职的时候,由于上面的项目框架问题太多,之前也尝试过解决,但,解决不了,领导也意识到了这点,而且也有新项目进来,就让我重新搞一套项目框架。所以,我自研了一套基于 Webpack
的项目框架和工程化体系,做这件事的目的,就如我上面提到过的一样,提升整个前端团队的开发效率、按时交付、保证交付质量。
我们使用的是 Git Flow
分支管理策略
Git Flow
最开始是由 Vincent Driessen
发行并广受欢迎,这个模型是在 2010 年构思出来的,而现在距今已有 10 多年了,而 Git
本身才诞生不久。在过去的十年中,Git Flow
在许多软件团队中非常流行
master || main
分支上的产品要求随时处于可部署状态。master || main
分支只能通过与其他分支合并来更新内容,禁止直接在 master || main
分支进行修改。develop
分支上的产品可以是缺失功能模块的半成品,但是已有的功能模块不能是半成品。develop
分支只能通过与其他分支合并来更新内容,禁止直接在 develop
分支进行修改。feature
分支,并在 feature
分支上进行开发。开发完成后,需要将该 feature
分支合并到 develop
分支,最后删除该 feature
分支。develop
分支上的项目准备发布时,从 develop
分支上创建一个新的 release
分支,新建的 release
分支只能进行质量测试、bug 修复、文档生成等面向发布的任务,不能再添加功能。这一系列发布任务完成后,需要将 release
分支合并到 master
分支上,并根据版本号为 master
分支添加 tag
,然后将 release
分支创建以来的修改合并回 develop
分支,最后删除 release
分支。master
分支中的产品出现需要立即修复的 bug 时,从 master
分支上创建一个新的 hotfix
分支,并在 hotfix
分支上进行 BUG 修复。修复完成后,需要将 hotfix
分支合并到 master
分支和 develop
分支,并为 master
分支添加新的版本号 tag
,最后删除 hotfix
分支。提交信息应该描述“做了什么”和“这么做的原因”,必要时还可以加上“造成的影响”,主要由 3 个部分组成:Header
、Body
和 Footer
。
Header
Header 部分只有 1 行,格式为<type>(<scope>): <subject>
。
type 用于说明提交的类型,共有 8 个候选值:
subject 用于概括提交内容。
Body 省略
Footer 省略
这样做起来的好处,这个项目下:
Tag
都上线了什么内容。总之,一目了然。
在这个流程中,开发人员只对个人仓库拥有可控权,无法直接改变公司仓库代码,当需要提交到公司仓库下时,需要发起 PR
请求,经过组长 CR
后,将其代码合并到公司仓库下。
主分支代码和线上代码进行隔离,由组长将指定版本的 Tag
发布到生产环境,再通过运营人员直接从 GitLab
上拉取指定的 Tag
,然后打包发布。
通过以上流程,前端代码能保证高质量,高稳定性的状态,运行在服务器端。
要根据实际业务情况和团队规模,技术水平来做,关键是要形成一个闭环,所谓闭环就是从零开始到上线再到迭代的全链路,有很多节点,这些节点需要根据实际情况进行设计,避免过度设计。
为何不是 create-react-app
create-react-app 是基于 webpack
的打包层方案,包含 build、dev、lint
等,他在打包层把体验做到了极致,但是不包含路由,不是框架,也不支持配置。所以,如果大家想基于他修改部分配置,或者希望在打包层之外也做技术收敛时,就会遇到困难。
为何不是 umi
umi 提供的功能很多,这也导致它太过于臃肿。而且你还要去学它的封装化配置,而不是学原生第三方库的配置,如果你只想要一些简单的功能,追求更高的可玩性,哪 umi 不太适合。
所以,我自己定制了一套脚手架,实现了以下功能:
解决了以下的问题:
完成整个编码过程的一个闭环:
这些节点要视实际情况,以最小成本去做,然后逐步升级。比如编码规范,我们是采用业界比较著名的 Airbnb JavaScript
代码规范,搭配eslint、pre-commit、lint-staged、prettier、stylelint
去进行约束。
这套项目框架,目前开发体验非常爽,在我司多个产品线上,投入使用,并已开源,框架地址,演示页面比较少,大佬们觉得不错的话,可以给个 Star