如何设计一个前端项目

因此我们在设计一个项目的时候，需要重点关注：

技术方案的设计和选型。

多人协作和团队规范的制订。

技术方案设计和选型

从 0 开始搭建一个项目，常常需要考虑以下的技术选型：

1. 前端框架和脚手架。

2. 状态管理工具。

3. 路由管理工具。

4. 代码构建和编译工具。

技术选型的影响因素

一般来说，从头开始搭建前端项目，首先要思考几个问题。

项目规模如何、功能交互是否复杂、面向哪些用户？

是否存在多人协作？团队规模大概是怎样的？

团队成员技术栈如何？对新技术的接受程度怎样？

是否有现有的技术方案可以参考？是否需要进行调整？

为什么要考虑这些问题呢？

项目规模和功能交互会影响框架和工具的选型，比如轻量项目可能 React/Vue 框架比较灵活，大型项目还可以使用 Angular 全家桶。

用户体系会影响系统兼容性的倾向，比如用户受众年龄偏大，则需要考虑使用机型性能可能相对较差、需兼容的机型品牌比较多。

存在多人协作需要考虑完善团队规范，同时尽量使用工具来保证流程规范。

团队技术栈倾向同样影响技术选型，如果有现成的技术方案和项目案例，可以考虑是否符合实际需要，使用团队成员熟练的工具可以避免很多踩坑的过程。

使用一致的代码开发规范

可以使用一些工具来确保代码符合规范：

1. 使用 Eslint 检测代码规范；

2. 使用 Prettier 自动化格式代码；

3. 使用 Git Commit Hooks 拒绝不符合规范的代码提交；

4. 使用流水线检测出不规范的代码，并拒绝合入主干分支；

5. 使用流水线检测出不规范的代码，并拒绝进入发布流程。

制定合适的代码流程规范

一般来说，开发流程会包括：

1. Git 创建分支过程：分支的命名，是否需要关联需求单或是 BUG 单。

2. Git 提交代码过程：检查代码是否符合规范，只允许合格的代码（Eslint 规范、单测覆盖率等）进行提交。

3. 分支提交过程：需要进行交叉 Code Review，对方同意后才允许合入代码。

4. 合入主干过程：对代码进行自动化构建和测试，功能正常且符合规范的代码才可合入主干。

5. 代码发布过程：自动拉取主干分支，创建发布分支，对代码进行自动化构建和测试，正常后会开始进入灰度发布流程。

通过自动化的工具我们同样可以确保以上流程按预期进行，很多团队也会使用持续集成（continuous integration，简称 CI）和持续部署（continuous deployment，简称 CD）。CI/CD 在项目中的落地，很多时候会表现为流水线的开发模式。

1. 系统质量的下降

1.1 项目频繁地调整（新增或者更换）开发人员，由于不熟悉项目，每个新加入的小伙伴都可能会埋下新的 Bug； 1.2 系统功能新增和迭代、不断壮大，各个模块间的耦合增加、复杂度增加，如果没法掌握系统的所有细节，很可能牵一发而动全身，产生自己认知以外的 Bug。

为了降低系统的复杂度，当项目发展到一定阶段的时候，会对系统进行局部或是整体的架构调整，比如模块的拆分、各个模块间的依赖解耦、引入新的状态管理工具、重复逻辑进行抽象和封装，等等。

1. 用户反馈问题跟进和定位；

2. 线上 Bug 修复和紧急发布；

3. 处理系统的监控告警，排查异常问题；

4.新功能灰度发布过程，自测、产品验证功能、提测、修复 Bug、灰度发布等各个流程都需要人工操作和主动关注；

1. 为了保证系统质量，需要完善自动化测试能力，包括单元测试、UI 测试、集成测试等；

5.项目成员的调整，需要进行工作的交接、指导对方的工作内容等。

提升系统质量： 项目设计和架构优化

1. 引入新的技术和工具的同时，需要考虑是否能兼容原有设计、团队成员熟悉成本、改造的工作量和预期的效果，选择性价比合适的方案落地。

2. 团队成员增加，沟通成本和对规范的理解出现差异。使用工具（Eslint/Prettier/Git hooks 等）将团队规范进行落地，保证开发过程中使用一致的技术栈、代码规范以及公共物料库（组件库、工具库），降低团队的沟通成本，确保代码的可读性和可维护性。

3. 项目功能模块过多，需要进行模块的拆分和解耦。将一些职责独立的模块进行拆包，使用 monorepo 或是 multirepo 的方式进行管理，模块可自行对技术方案、依赖关系梳理、变更、测试、发布等环节进行闭环，从而降低各个模块间的相互影响，降低系统的复杂度。

4. 项目代码量和文件数的增加，除了进行拆包以外，还需要更新或是优化项目构建工具（使用增量编译、使用 Tree-shaking、升级 Webpack 版本等），减少代码编译、打包等过程的耗时，提升开发效率。

5. 进行自动化测试能力的覆盖，补齐单模块的功能测试、各个模块间的集成测试、UI 组件的界面测试、接口的模拟环境测试、性能测试等。在每次系统发布的时候都可以自动化进行回归测试，避免某个改动影响了其他的功能模块、带来了认知以外的风险，确保系统质量不受影响。

6. 搭建完善的监控体系，在系统灰度、发布、线上运行的过程中可实时观察系统质量，配合告警能力及时发现问题并进行解决，保证系统运行的稳定性。

提升开发效率：项目研发和发布流程优化

项目研发和发布流程优化的核心点在于：将一切需要手动操作和关注的内容自动化。

从主干创建分支，开始进入开发；

开发完成后，补充相关自动化测试（单元测试、集成测试、UI 测试等）；

进行自动化测试的回归，确保系统整体功能能正常运行；

构建代码，部署测试环境，进入产品体验和测试流程；

修复产品体验问题和 Bug，并重复 2~4 步骤；

代码验证完成，进行团队内代码 Review 后，更新主干的分支，并进行代码构建和自动化回归测试；

根据团队 Git 规范（比如 Git Flow 流程），准备发布；

先进行版本灰度，灰度过程中登录监控系统关注各个指标是否有异常；

如果监控系统出现异常，进行问题定位，并在 Bug 修复之后返回到步骤 2；

灰度过程无异常，进行全量发布，发布完后同样观察监控系统是否有异常；

全量发布完成，结束需求单，并将版本进行归存（使用分支或者 git tag）。

---

持续集成（CI）：目的是让产品可以快速迭代，同时还能保持高质量。

持续部署（CD）：目的是代码在任何时刻都是可部署、可进入生产阶段。

CI/CD流水线

模块耦合严重

1. 模块职责和边界定义不清晰，导致模糊的工作可能存在多个模块内；

2. 各个模块没有统一管理，导致模块在状态变更时需要手动通知相关模块；

3. 模块间的通信方式设计不合理，导致全局事件满天飞、A 模块内直接调用 B 模块等问题，隐藏的引用和事件可能导致内存泄漏。

解局之道：

1.项目规模调整后，对现有架构设计进行分析，如果不再合适则需要进行及时调整和优化。 2. 使用模块解耦的技术方案，将各个模块统一交由框架处理。 3. 梳理各个模块的职责，明确每个模块负责的工作和提供的功能，确定各个模块间的边界和调用方式。

常见考点: • 冒泡 / 快排 - 排序类算法 • LRU / 排列组合 - 应⽤类算法 • 链表 / 堆 / 栈 / 树 / 图 - 数据结构类算法 • 分治 / 动规 - 算法思想 • 深度优先 / ⼴度优先

前端工程化体系实现高效交付

如何进行合理的分工排期

进行工作量评估的过程可以分为三步：

1. 确认技术方案，以及分工合作方式；

2. 拆分具体功能模块，分别进行工作量评估，输出具体的排期时间表；

3. 标注资源依赖情况和协作存在的风险，进行延期风险评估。

当我们确认好技术方案之后，需要针对实现细节拆分具体的功能模块，分别进行工作量的预估和分工排期。否则可能面临分工不明确、接口协议未对齐就匆忙开工、最终因为各种问题而返工等情况。

我们在进行工作量评估的时候，可以精确到半天的工作量预期。对独自开发的项目来说，同样可以通过拆解功能模块这个过程，来思考具体的实现方式，也能提前发现一些可能存在的问题，并相应地进行规避。

提供完整的工作量评估和排期计划表（精确到具体的日期），可以帮助我们有计划地推进项目。在开发过程中，我们可以及时更新计划的执行情况，团队的其他人也可以了解我们的工作情况。

工作量评估和排期计划表的另外一个重要作用，是通过时间线去严格约束我们的工作效率、及时发现问题，并在项目结束后可针对时间维度进行项目复盘。

为了确保项目能按照预期进行，我们还要对可能存在的风险进行分析，提前做好对应的准备措施