我是如何突围传统行业的？

背景

自我介绍下，四年工做经验，头两年全栈开发，后两年专职作前端，目前已达到高级前端工程师水平，经历过三家公司。第一家公司，电商行业，作阿里 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 设计稿不规范

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

明确本身的任务

前端技术建设的核心目的，是为了提升开发效率，保证开发质量，为保障项目高质量按时交付，同时兼顾考虑中长期研发实际状况，结合团队实际能力，为将来作技术储备，为业务发展提供更多的可能性，大概将本身的分为如下四类

• 基础架构设计，主要目的是从架构层面出发，经过流程化设计，规避常见问题，提升开发效率。
• 工程化设计，与代码强相关，主要目的是提升代码质量，加强代码的长期可维护性，下降开发时间和成本。
• 团队管理，经过合理有效的团队管理，提升团队人效比，为将来项目研发、技术发展，进行人才储备、技术研发。
• 项目管理，进行合理的项目管理，合适的工时排期和迭代计划，提升项目交付质量和效率。

如何解决

首先，要对现有的问题进行梳理概括，按照问题的优先级进行排序，而后，分阶段性目标进行实现，对于上面的问题，我大概整理了一张表格

问题	优先级	成本	目标
如何打造前端工程化体系	p0	高	提高整个前端团队的开发效率、按时交付、保证交付质量。
如何进行团队管理	p0	中	进行人才储备，提升团队人员技术能力
如何进行项目管理	p1	中	掌控全局，知道项目下的人都在作什么，资源协调

团队管理

人员管理

• 初来乍到，首先就是跟你们一块儿聊聊天，了解他/她的想法，以及我的状况、技术能力、兴趣爱好、性格特色等。

• 团建聚餐，常常请你们喝奶茶/咖啡，不定时的组织活动，一般是聚餐（我的出钱），为下面的工做，好开展。

• 导师帮带，新人进来后，安排一我的带着他，答复常见问题，由简单的需求再到核心模块的负责，一点一点施展压力。

• 新人适应，负责安排新成员的发展方向，并在新人入职的前几周，了解项目框架和开发模式，再安排其作基于现有页面的优化，帮助其了解不一样人负责的业务。

• 责任划分，明确团队里人员定位，并使其知晓，根据成员能力不一样，态度不一样，安排适合其的任务。

• 前端周会，每周一次，组织你们开前端周会，在这个会上，过下你们目前手头上的事情，有没有遇到什么问题，须要协调的一些资源，进度把控等。

• 技术分享，不定时的前端技术分享，主题不限，并把相关分享后的资料，上传到前端文档管理，方便往后的人员进行查看。

权限管理

主要是指代码权限控制，目的是确保代码安全，问题可控可避免可追溯

具体管理举措有如下几条：

• 公司仓库，代码属于公司财产，对代码进行权限隔离，启用内网 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 组件来的。

这样带来的好处就是尽可能避免定制化的开发，全部列表和详情都是按照这种风格来进行开发。

执行成果

开发效率

组内人员开发效率，较以前提高了一倍左右，普通的列表页面（搜索、展现、弹窗 ），包含接口联调 + 自测，大概 1 天左右完成，详情页面，复杂一点的表单交互，表单组件联动，大概在 2 天左右完成，包含接口联调 + 自测，目前咱们也在探索 Vite，Snowpack，极大的提高开发体验。

系统状况

SaaS 系统，首次无缓存加载耗时 3.22s ，三个系统（ 30 多个页面，14 个公用组件）打包出来的体积在 9.3MB

固然还有优化空间

设计规范

目前大部分页面不须要设计资源投入，尽可能按照 Ant Design 设计标准和咱们自定的 UI 标准风格来作，减小设计人员的工做投入。

项目文档

目前全部的产品文档，技术文档都很是规范，能够溯源，以及当时在什么样的场景下，为何要作出这样的解决方案。

总结

上面这些，包含其余的，大概花了一年多的时间，建设完成，咱们目前的基建情况以下表所示

若是你以为对你有帮助或启发，欢迎点赞留言。