详细地讲述我是如何从传统行业突出重围的

我就是我 2022-10-16 15:19 123阅读 0赞

点击上方 前端Q，关注公众号

回复加群，加入前端Q技术交流群

# 背景 #

自我介绍下，四年工作经验，头两年全栈开发，后两年专职做前端，目前已达到高级前端工程师水平，经历过三家公司。第一家公司，电商行业，做阿里 `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 发生生产事故，事故表现为，操作特定页面，浏览器崩溃，卡死。

![77d514a3627e28d5d295d1ae9c22b72a.png][]

脚本执行时间非常长，后面经查，是由以下代码引起

actions.getAgentListByPage({
        companyId: currentAgent.companyId,
        pageIndex: 1,
        pageSize: 20000,
        searchProvince: currentAgent.province,
        searchCity: currentAgent.city
    })

页面很多地方存在请求 **「pageSize：20000」** 的情况，该代码是由前任前端编写，具体为何写出这样的代码，原因未知，处理方案给到后端解决，前端配合加入`workbench` 字段，凌晨 1 点左右得到解决。

一套项目上，运行着两套系统。

打包出来的项目代码体积有 **「49.5MB」**，页面首次加载耗时 **「11.4 min」**

![f43dc33d40cc53c95335c322f2f817bb.png][]

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

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

## 项目人员能力较弱 ##

*  测试同学报备 BUG，没有记录可复现步骤。
 *  任务管理工具平台没有真正利用起来，相关项目需求，BUG 没有整理起来放在上面。
 *  产品不理解大概的技术实现，没有把产品文档梳理，留存下来，不理解客户的真正需求，以至于技术实现比较鸡肋。

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

## 产品画的原形 和 UI 设计稿不规范 ##

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

# 明确自己的任务 #

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

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

# 如何解决 #

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

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

## 团队管理 ##

### 人员管理 ###

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

### 权限管理 ###

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

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

*  **「公司仓库」**，代码属于公司财产，对代码进行权限隔离，启用内网 `GitLab`，默认关闭所有外网访问权限，针对每个项目，按实际需要给开发赋予指定权限。
 *  **「提交权限」**，允许开发在自己仓库下提交，但涉及到公司仓库的合并，需要发起`PR`，然后在组长进行 `CR` 后，才能提交到主仓库。
 *  **「发布权限」**，对于将要发布到生产环境，权限给到组长，只允许组长进行发布。

### 前后端接口对接 ###

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

因此，通过梳理开发流程，出接口文档，作为对接标准。

我们使用 `apiDoc` 来作为前后端联调标准。

![18ff1c4f6adfeda429dba64382888a8a.png][]

但在实际情况中，还是会有一些接口文档和实际接口不符的情况发生，导致一些问题产生，这个我们也在思考。

## 前端工程化体系 ##

刚入职的时候，由于上面的项目框架问题太多，之前也尝试过解决，但，解决不了，领导也意识到了这点，而且也有新项目进来，就让我重新搞一套项目框架。所以，我自研了一套基于`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 省略

![6f36e1175164240e3074983fd96116e0.png][]

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

*  对于分支，每个人在做什么，我看分支就清楚。
 *  对于修改内容，看前缀就知道这个文件改动了什么。
 *  对于版本迭代，看 `Tag` 都上线了什么内容。

总之，一目了然。

#### 开发人员基本流程 ####

![34c22b1ffe744710d163b8f3203c13dc.png][]

在这个流程中，开发人员只对个人仓库拥有可控权，无法直接改变公司仓库代码，当需要提交到公司仓库下时，需要发起 `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` 去进行约束。

这套项目框架，目前开发体验非常爽，在我司多个产品线上，投入使用，并已开源，**「框架地址\[1\]」**，演示页面比较少，大佬们觉得不错的话，可以给个 Star ????，也欢迎给项目提 issues ～

#### 业务场景 ####

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

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

如果子系统特别复杂，有主从系统概念，可以考虑使用微服务设计，这里不做过多介绍。

#### 静态资源 ####

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

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

我们是放在 `S3` 上，做 `CDN` 静态资源加速，然后前端项目通过引入`url` 来使用这些资源，这样可以减轻自己的服务器网络带宽消耗。

## 项目管理 ##

*  **「任务分配」**，产品把相关的需求，经过讨论，可行性分析，通过项目管理工具，放到迭代计划中，录入开发工时，测试工时。
 *  **「文档管理」**，采用项目管理工具自带的文档，要求做到文档可以团队编辑，可以查看到编辑历史。
 *  **「项目周会」**，过大家手上目前的迭代进度，遇到的问题，需要协调的资源，风险控制等。
 *  **「项目复盘」**，复盘首先是要做的是事实陈述，开始诊断、分析存在差异的原因，找出导致成功或失败的根本原因后进行规律总结。明白为什么会成功、哪些关键行为起了作用，这些行为有没有适用条件，对于提高后续行动的成功率有没有价值。

### 熟悉产品线业务 ###

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

画出产品架构图

![ab701b97c1bcdc772d53feaae318be43.png][]

### 提升相关人员的能力 ###

#### 产品人员 ####

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

所以对产品经理的要求非常严格，因为一个公司，如果战略方向把握住了，那么核心是要看产品，能否把握住市场方向，非常关键。这样才能决定你是否能占有市场，由于我司是做一个`ToB SaaS` 化的平台，所以，必须要求产品经理清楚的了解客户实际需求，需求背后的实际场景，提炼出来哪些是共性的需求，哪些是客户定制化的需求，然后再讨论，再进行落地实际的开发。

#### 测试人员 ####

对测试人员，尽量覆盖全所有场景，保证核心流程畅通，要求能找到复现步骤，提高开发解决 BUG 的效率。

### 设计规范 ###

由于我司采用的是 `Ant Design` UI 库，所以设计标准，尽量都是按照 `Ant Design`现成组件和样式来做，避免开发二次修改，参考这个链接 Ant Design 设计原则\[2\]

某个列表页

![74cc0fbcc8dea529dc13561ee6cd8349.png][]

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

某个详情页

![19e8f8fbd4d749b6a87c6ad2e89ffdf3.png][]

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

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

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

# 总结 #

上面这些，包含其他的，大概花了一年多的时间，建设完成，我们目前的基建状况如下表所示

![dcaafc0051aaa9050619eb547e5efe22.png][]

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

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

如果你觉得对你有帮助或启发，欢迎点赞转发。

### Reference ###

\[1\]

框架地址:https://github.com/xuya227939/tristana.git

\[2\]

Ant Design 设计原则:https://ant.design/docs/spec/introduce-cn

声明：文章著作权归作者所有，如有侵权，请联系小编删除。

内推社群

我组建了一个氛围特别好的腾讯内推社群，如果你对加入腾讯感兴趣的话（后续有计划也可以），我们可以一起进行面试相关的答疑、聊聊面试的故事、并且在你准备好的时候随时帮你内推。下方加 winty 好友回复「面试」即可。

![a162bf2a834ddbf070607ebfb5a629cd.png][]

[77d514a3627e28d5d295d1ae9c22b72a.png]: /images/20221014/a5e3c0ea9ce34a6c86acd5d2ba6586bc.png
[f43dc33d40cc53c95335c322f2f817bb.png]: /images/20221014/f9a95cb0a84648f38c7025f24a986628.png
[18ff1c4f6adfeda429dba64382888a8a.png]: /images/20221014/8698f834b5aa43a6baf76a9a963d2302.png
[6f36e1175164240e3074983fd96116e0.png]: /images/20221014/6ea10cdbcc1e4adb874d2f30a25517f1.png
[34c22b1ffe744710d163b8f3203c13dc.png]: /images/20221014/99831921c82444aba49a99bdba26ec27.png
[ab701b97c1bcdc772d53feaae318be43.png]: /images/20221014/3deb005403f84df9be62fc9558b8d306.png
[74cc0fbcc8dea529dc13561ee6cd8349.png]: /images/20221014/2495b2b1e52c4c8f95f666a2edb4a16c.png
[19e8f8fbd4d749b6a87c6ad2e89ffdf3.png]: /images/20221014/adef08e29c884bf6ab63bf46dddd3008.png
[dcaafc0051aaa9050619eb547e5efe22.png]: /images/20221014/bf665fef06e14d09a1be3765cd7c6cc8.png
[a162bf2a834ddbf070607ebfb5a629cd.png]: /images/20221014/cfeb252ffe3548b19d53df5a2c065f03.png