「前端」如何搭建前端架构和团队体系心得分享

架构思考 08-09 337

前言：

目前姐妹们对“javaweb架构图”大概比较关心，各位老铁们都想要剖析一些“javaweb架构图”的相关内容。那么小编也在网络上收集了一些关于“javaweb架构图””的相关文章，希望小伙伴们能喜欢，大家快快来学习一下吧！

一、背景

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

二、入职时的环境

这是一家做保险和金融行业的公司，属于传统行业的科技公司，有点外包的性质，当然，也有自己的 SaaS 产品，由于是传统行业的公司，技术栈相对互联网公司来说，稍微落后一点。我刚来的时候，上一个前端要辞职了，然后做对接工作（告诉我，有啥问题，直接搜代码），我算是接盘侠，前任留下的屎山，其他的，大概有以下几点：

2.1 前端组 4 个人

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

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

没有前端工程化体系，开发周期长，开发质量差，维护困难。前后端混合项目，剥离前端代码没有剥离干净，后端很多文件都在，不知道重不重要，前端代码运行在服务端，每次修改一行代码，看效果，需要拖到服务器上进行编译，编译大概 1-2 分钟左右，非常痛苦。完全熟悉该项目的人员已离职（技术和产品），项目交接没有处理好。业务逻辑非常混乱，没有相关的产品流程图，全凭记忆。服务器上运行的 Node 版本非常低，到现在还是 8.x，各种低版本的库都在，比如 Ant Design 用的 3.6.2，在项目开发中遇到穿梭框无法进行树状显示(代码一摸一样，在高版本 3.19.2，可以显示)。又比如还有这种 "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。

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

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

2.3 项目人员能力较弱

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

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

不多说了，懂得都懂，吃午饭的时候说两句就算对接了。

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

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

三、明确自己的任务

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

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

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

问题

优先级

成本

目标

如何打造前端工程化体系

高

提升整个前端团队的开发效率、按时交付、保证交付质量。

如何进行团队管理

中

进行人才储备，提高团队人员技术能力

如何进行项目管理

中

掌控全局，知道项目下的人都在做什么，资源协调

4.1 团队管理

4.1.1 人员管理

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

4.1.2 权限管理

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

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

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

4.1.3 前后端接口对接

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

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

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

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

4.2 前端工程化体系

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

4.2.1 基础架构设计

Git 分支管理规范化

我们使用的是 Git Flow 分支管理策略

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

（1）分支命名规范

master 分支：master 分支只有一个，名称即为 master。GitHub 现在叫 maindevelop 分支：develop 分支只有一个，名称即为 developfeature 分支：feature/<功能名>，例如：feature/login，以便其他人可以看到你的工作hotfix 分支：hotfix/日期，例如：hotfix/0104

（2）分支说明

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）提交信息规范

提交信息应该描述“做了什么”和“这么做的原因”，必要时还可以加上“造成的影响”，主要由 3 个部分组成：Header、Body 和 Footer。

Header

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

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

feat：新功能（feature）fix：问题修复docs：文档style：调整格式（不影响代码运行）refactor：重构test：增加测试chore：构建过程或辅助工具的变动revert：撤销以前的提交scope 用于说明提交的影响范围，内容根据具体项目而定。

subject 用于概括提交内容。

Body 省略

Footer 省略

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

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

总之，一目了然。

开发人员基本流程：

在这个流程中，开发人员只对个人仓库拥有可控权，无法直接改变公司仓库代码，当需要提交到公司仓库下时，需要发起 PR 请求，经过组长 CR 后，将其代码合并到公司仓库下。

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

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

4.2.2 工程化设计

要根据实际业务情况和团队规模，技术水平来做，关键是要形成一个闭环，所谓闭环就是从零开始到上线再到迭代的全链路，有很多节点，这些节点需要根据实际情况进行设计，避免过度设计。

定制 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 ～

（1）业务场景

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

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

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

（2）静态资源

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

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

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

4.3 项目管理

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

4.3.1 熟悉产品线业务

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

画出产品架构图

4.3.2 提升相关人员的能力

产品人员

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

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

测试人员

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

设计规范

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

某个列表页

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

某个详情页

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

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

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

五、执行成果

5.1 开发效率