背景

自我介绍下，四年工作教训，头两年全栈开发，后两年专职做前端，目前已达到高级前端工程师程度，经验过三家公司。第一家公司，电商行业，做阿里 ISV 供应商，为淘宝卖家服务，也是我第一次接触百万 UV 级别的产品，在第一家公司呆了两年，因为达到技术瓶颈期，随跳槽，第二家公司，航运物流行业，呆了六个月（工作强度对我来说，是真的高），身材不适，没有批准转正。目前这家，负责项目管理和前端组长，两个角色，目前呆了两年，做了很多货色，把本人的一些想法跟大家聊一聊。

入职时的环境

这是一家做保险和金融行业的公司，属于传统行业的科技公司，有点外包的性质，当然，也有本人的 SaaS 产品，因为是传统行业的公司，技术栈绝对互联网公司来说，略微落后一点。我刚来的时候，上一个前端要辞职了，而后做对接工作（通知我，有啥问题，间接搜代码），我算是接盘侠，后任留下的屎山，其余的，大略有以下几点：

前端组 4 集体

其中一个归 CTO（做后端）管，另外两个在广东，我入职的时候，也没有确认，到底要不要带人。我来的时候，就曾经在了，前面我领导跟我说，要带下他们，我过后压根就没有带人的想法，也是个坑。

历史我的项目有很多个，都是基于一套从 GitHub 上弄过去的我的项目框架

• 没有前端工程化体系，开发周期长，开发品质差，保护艰难
• 前后端混合我的项目，剥离前端代码没有剥离洁净，后端很多文件都在，不晓得重不重要，前端代码运行在服务端，每次批改一行代码，看成果，须要拖到服务器上进行编译，编译大略 1-2 分钟左右，十分苦楚。
• 齐全相熟该项目标人员已到职（技术和产品），我的项目交接没有解决好。
• 业务逻辑十分凌乱，没有相干的产品流程图，全凭记忆。
• 服务器上运行的 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

基于以上的起因，向领导提出过重构，没有批准，我认为可能有两个方面的顾虑，

• 从人力资源条件来讲，并不容许。
• 从公司策略角度来讲，能挣钱的我的项目就是好我的项目。然而，这并不影响我建设前端工程化体系。

我的项目人员能力较弱

• 测试同学报备 BUG，没有记录可复现步骤。
• 工作管理工具平台没有真正利用起来，相干我的项目需要，BUG 没有整顿起来放在下面。
• 产品不了解大略的技术实现，没有把产品文档梳理，留存下来，不了解客户的真正需要，以至于技术实现比拟鸡肋。

前后端接口对接，没有相干的文档

产品画的原形 和 UI 设计稿不标准

列举了以上的这些点，烂摊子太多了，好在有一个点，领导的反对力度还不错，看我是如何解围的。

明确本人的工作

前端技术建设的外围目标，是为了进步开发效率，保障开发品质，为保障我的项目高质量按时交付，同时兼顾思考中长期研发理论状况，联合团队理论能力，为将来做技术储备，为业务倒退提供更多的可能性，大略将本人的分为以下三类

• 基础架构设计 ，次要目标是从架构层面登程，通过流程化设计，躲避常见问题，进步开发效率。
• 工程化设计 ，与代码强相干，次要目标是进步代码品质，加强代码的长期可维护性，升高开发工夫和老本。
• 团队治理 ，通过正当无效的团队治理，进步团队人效比，为将来我的项目研发、技术倒退，进行人才储备、技术研发。
• 项目管理 ，进行正当的项目管理，适合的工时排期和迭代打算，进步我的项目交付品质和效率。

如何解决

首先，要对现有的问题进行梳理演绎，依照问题的优先级进行排序，而后，分阶段性指标进行实现，对于下面的问题，我大略整顿了一张表格

团队治理

人员治理

• 初来乍到 ，首先就是跟大家一起聊聊天，理解他 / 她的想法，以及集体状况、技术能力、兴趣爱好、性格特点等。
• 团建聚餐 ，常常请大家喝奶茶 / 咖啡，不定时的组织流动，通常是聚餐（集体出钱），为上面的工作，好发展。
• 导师帮带 ，新人进来后，安顿一个人带着他，回答常见问题，由简略的需要再到外围模块的负责，一点一点施展压力。
• 新人适应 ，负责安顿新成员的倒退方向，并在新人入职的前几周，理解我的项目框架和开发模式，再安顿其做基于现有页面的优化，帮忙其理解不同人负责的业务。
• 责任划分 ，明确团队里人员定位，并使其通晓，依据成员能力不同，态度不同，安顿适宜其的工作。
• 前端周会 ，每周一次，组织大家开前端周会，在这个会上，过下大家目前手头上的事件，有没有遇到什么问题，须要协调的一些资源，进度把控等。
• 技术分享 ，不定时的前端技术分享，主题不限，并把相干分享后的材料，上传到前端文档治理，不便日后的人员进行查看。

权限治理

次要是指代码权限管制，目标是确保代码平安，问题可控可防止可追溯

具体治理动作有以下几条：

• 公司仓库 ，代码属于公司财产，对代码进行权限隔离，启用内网 GitLab，默认敞开所有外网拜访权限，针对每个我的项目，按理论须要给开发赋予指定权限。
• 提交权限 ，容许开发在本人仓库下提交，但波及到公司仓库的合并，须要发动 PR，而后在组长进行 CR 后，能力提交到主仓库。
• 公布权限 ，对于将要公布到生产环境，权限给到组长，只容许组长进行公布。

前后端接口对接

前后端开发联调有一个重大问题，就是后端接口变动或者字段改变时，没有在事前事后告诉相应前端开发，测试人员，导致效率底下，并且会呈现各种异常情况。

因而，通过梳理开发流程，出接口文档，作为对接规范。

咱们应用 apiDoc 来作为前后端联调规范。

但在理论状况中，还是会有一些接口文档和理论接口不符的状况产生，导致一些问题产生，这个咱们也在思考。

前端工程化体系

刚入职的时候，因为下面的我的项目框架问题太多，之前也尝试过解决，但，解决不了，领导也意识到了这点，而且也有新我的项目进来，就让我从新搞一套我的项目框架。所以，我自研了一套基于 Webpack 的我的项目框架和工程化体系，做这件事的目标，就如我下面提到过的一样，晋升整个前端团队的开发效率、按时交付、保障交付品质。

基础架构设计

Git 分支治理规范化

咱们应用的是 Git Flow 分支管理策略

Git Flow 最开始是由 Vincent Driessen 发行并广受欢迎，这个模型是在 2010 年构思进去的，而当初距今已有 10 多年了，而 Git 自身才诞生不久。在过来的十年中，Git Flow 在许多软件团队中十分风行

分支命名标准

• master 分支：master 分支只有一个，名称即为 master。GitHub 当初叫 main
• develop 分支：develop 分支只有一个，名称即为 develop
• feature 分支：feature/< 性能名 >，例如：feature/login，以便其他人能够看到你的工作
• hotfix 分支：hotfix/ 日期，例如：hotfix/0104

分支阐明

• master || main 分支：存储正式公布的产品，master || main 分支上的产品要求随时处于可部署状态。master || main 分支只能通过与其余分支合并来更新内容，禁止间接在 master || main 分支进行批改。
• develop 分支：汇总开发者实现的工作成绩，develop 分支上的产品能够是缺失功能模块的半成品，然而已有的功能模块不能是半成品。develop 分支只能通过与其余分支合并来更新内容，禁止间接在 develop 分支进行批改。
• feature 分支：当要开发新性能时，从 master 分支创立一个新的 feature 分支，并在 feature 分支上进行开发。开发实现后，须要将该 feature 分支合并到 develop 分支，最初删除该 feature 分支。
• release 分支：当 develop 分支上的我的项目筹备公布时，从 develop 分支上创立一个新的 release 分支，新建的 release 分支只能进行品质测试、bug 修复、文档生成等面向公布的工作，不能再增加性能。这一系列公布工作实现后，须要将 release 分支合并到 master 分支上，并依据版本号为 master 分支增加 tag，而后将 release 分支创立以来的批改合并回 develop 分支，最初删除 release 分支。
• hotfix 分支：当 master 分支中的产品呈现须要立刻修复的 bug 时，从 master 分支上创立一个新的 hotfix 分支，并在 hotfix 分支上进行 BUG 修复。修复实现后，须要将 hotfix 分支合并到 master 分支和 develop 分支，并为 master 分支增加新的版本号 tag，最初删除 hotfix 分支。

提交信息标准

提交信息应该形容“做了什么”和“这么做的起因”，必要时还能够加上“造成的影响”，次要由 3 个局部组成：Header、Body 和 Footer。

Header
Header 局部只有 1 行，格局为 <type>(<scope>): <subject>。

type 用于阐明提交的类型，共有 8 个候选值：

1. feat：新性能（feature）
2. fix：问题修复
3. docs：文档
4. style：调整格局（不影响代码运行）
5. refactor：重构
6. test：减少测试
7. chore：构建过程或辅助工具的变动
8. revert：撤销以前的提交
9. scope 用于阐明提交的影响范畴，内容依据具体我的项目而定。

subject 用于概括提交内容。

Body 省略

Footer 省略

这样做起来的益处，这个我的项目下：

• 对于分支，每个人在做什么，我看分支就分明。
• 对于批改内容，看前缀就晓得这个文件改变了什么。
• 对于版本迭代，看 Tag 都上线了什么内容。

总之，高深莫测。

开发人员根本流程

在这个流程中，开发人员只对集体仓库领有可控权，无奈间接扭转公司仓库代码，当须要提交到公司仓库下时，须要发动 PR 申请，通过组长 CR 后，将其代码合并到公司仓库下。

主分支代码和线上代码进行隔离，由组长将指定版本的 Tag 公布到生产环境，再通过经营人员间接从 GitLab 上拉取指定的 Tag，而后打包公布。

通过以上流程，前端代码能保障高质量，高稳定性的状态，运行在服务器端。

工程化设计

要依据理论业务状况和团队规模，技术水平来做，要害是要造成一个闭环，所谓闭环就是从零开始到上线再到迭代的全链路，有很多节点，这些节点须要依据理论状况进行设计，防止适度设计。

定制 Webpack 我的项目框架

为何不是 create-react-app

create-react-app 是基于 webpack 的打包层计划，蕴含 build、dev、lint 等，他在打包层把体验做到了极致，然而不蕴含路由，不是框架，也不反对配置。所以，如果大家想基于他批改局部配置，或者心愿在打包层之外也做技术收敛时，就会遇到困难。

为何不是 umi

umi 提供的性能很多，这也导致它太过于臃肿。而且你还要去学它的封装化配置，而不是学原生第三方库的配置，如果你只想要一些简略的性能，谋求更高的可玩性，哪 umi 不太适宜。

所以，我本人定制了一套脚手架，实现了以下性能：

• 疾速上手 ，只有理解 React、Mobx、Webpack 和 React Router，就能够疾速搭建中后盾治理平台
• 路由零碎 ，基于 react-router 实现的路由零碎
• Loading，不须要反复写组件 Loading 判断
• 国际化 ，基于 react-intl-universal 实现的国际化
• 网络申请 ，基于 axios 实现的申请拦挡
• 页面交互 ，基于 mobx 实现的数据交互方式
• UI，应用业界最驰名的 ant-design
• 代码标准校验 ，应用 eslint、pre-commit、lint-staged、prettier、stylelint
• 模仿申请数据 ，基于 mockjs 实现
• 打包工具 ，目前最风行的 Webpack

解决了以下的问题：

• 束缚开发人员代码标准
• 不便提供给其余开发应用规范的脚手架，并提供技术支持

实现整个编码过程的一个闭环：

• 编码前：编码标准，最佳实际
• 编码中：自研我的项目框架、代码校验
• 编码后：公布部署工具 JenKins，手动公布或 CI/CD

这些节点要视理论状况，以最小老本去做，而后逐渐降级。比方编码标准，咱们是采纳业界比拟驰名的 Airbnb JavaScript 代码标准，搭配 eslint、pre-commit、lint-staged、prettier、stylelint 去进行束缚。

这套我的项目框架，目前开发体验十分爽，在我司多个产品线上，投入使用，并已开源， 框架地址 ，演示页面比拟少，大佬们感觉不错的话，能够给个 Star 🌟，也欢送给我的项目提 issues ～

业务场景

咱们是做 ToB 业务，存在页面上大量应用表单的场景，所以，把咱们的表单页面做成可配置化，实现了大部分页面表单配置化，缩小前端人力资源投入。

针对公司的理论业务场景，其余子系统不会特地简单，页面也不会多，共享一套账号体系，这里采纳的思路是只有一个我的项目，不分主从零碎，通过 Webpack 配置多页面，不同的子系统进入的首页内容不一样，加载内容不一样，菜单导航，则通过后端对每个租户进行辨别，来做到租户看到的菜单零碎不一样。

如果子系统特地简单，有主从零碎概念，能够思考应用微服务设计，这里不做过多介绍。

动态资源

除了业务代码以外，前端还会有一些公共动态资源，例如 React 资源，Ant Design 资源，BizCharts 资源，以及一些图片文件等。

对于这些文件，是所有我的项目所共享的，如果这些文件扩散在各个我的项目里，既没必要，也容易导致不同我的项目依赖文件不对立。

咱们是放在 S3 上，做 CDN 动态资源减速，而后前端我的项目通过引入 url 来应用这些资源，这样能够加重本人的服务器网络带宽耗费。

项目管理

• 任务分配 ，产品把相干的需要，通过探讨，可行性剖析，通过项目管理工具，放到迭代打算中，录入开发工时，测试工时。
• 文档治理 ，采纳项目管理工具自带的文档，要求做到文档能够团队编辑，能够查看到编辑历史。
• 我的项目周会 ，过大家手上目前的迭代进度，遇到的问题，须要协调的资源，危险管制等。
• 我的项目复盘 ，复盘首先是要做的是事实陈述，开始诊断、剖析存在差别的起因，找出导致胜利或失败的根本原因后进行法则总结。明确为什么会胜利、哪些要害行为起了作用，这些行为有没有实用条件，对于进步后续口头的成功率有没有价值。

相熟产品线业务

所谓技术服务业务，找产品理解现有的业务流程以及痛点，甚至将来要做的一些产品布局，好的技术架构，要思考各种各样的业务场景，怎样才能联合业务的复杂度，设计出颗粒度更加细化的组件。

画出产品架构图

晋升相干人员的能力

产品人员

需要频繁且凌乱，决策摇摆不定、动辄推倒重来。市面上一个好的产品经理是很贵的，没个三四万是拿不下一个真正靠谱的能抗住简单产品线的产品经理，然而很多公司老板是不违心花这个钱，个别就会招个工作一两年的产品经理先过去，顶个地位把这个工具给做进去就行了。恰好因为这样一个认知导致产品经理这一层他既没话语权，又不能让本人闲着，所以层出不穷的需要全堆上来了，而对于公司短暂型的产品架构就把控不住，如果一个产品经理无奈起到，上对客户负责，下对开发负责，不会对所有需要进行筛选，把需要只会丢给开发，不会进行工时把控和品质把控。甚至对现有产品有什么性能，都不理解，那么就不是一个合格的产品。

所以对产品经理的要求十分严格，因为一个公司，如果策略方向把握住了，那么外围是要看产品，是否把握住市场方向，十分要害。这样能力决定你是否能占有市场，因为我司是做一个 ToB SaaS 化的平台，所以，必须要求产品经理分明的理解客户理论需要，需要背地的理论场景，提炼进去哪些是共性的需要，哪些是客户定制化的需要，而后再探讨，再进行落地理论的开发。

测试人员

对测试人员，尽量笼罩全所有场景，保障外围流程畅通，要求能找到复现步骤，进步开发解决 BUG 的效率。

设计规范

因为我司采纳的是 Ant Design UI 库，所以设计标准，尽量都是依照 Ant Design 现成组件和款式来做，防止开发二次批改，参考这个链接 Ant Design 设计准则

某个列表页

一般的列表，和设计，产品都约定好，下面是筛选，上面是按钮，底部是表格展现。

某个详情页

详情页大量会应用到表单，所以间接应用 Ant Design 的 From 表单组件。

表单每行放多少个，都是以 Ant Design 组件来的。

这样带来的益处就是尽量避免定制化的开发，所有列表和详情都是依照这种格调来进行开发。

总结

下面这些，蕴含其余的，大略花了一年多的工夫，建设实现，咱们目前的基建情况如下表所示

前端人员的开发效率较之前，晋升了一倍左右的开发效率，前提是齐全相熟我这套我的项目框架的开发模式。

项目管理，人员工时占比，资源协调，目前下来都还不错，安稳进行。

如果你感觉对你有帮忙或启发，欢送点赞留言。