如何设计一个前端项目
因此我们在设计一个项目的时候，需要重点关注：
技术方案的设计和选型。
多人协作和团队规范的制订。
技术方案设计和选型
从 0 开始搭建一个项目，常常需要考虑以下的技术选型：
前端框架和脚手架。
状态管理工具。
路由管理工具。
代码构建和编译工具。
技术选型的影响因素
一般来说，从头开始搭建前端项目，首先要思考几个问题。
项目规模如何、功能交互是否复杂、面向哪些用户？
是否存在多人协作？团队规模大概是怎样的？
团队成员技术栈如何？对新技术的接受程度怎样？
是否有现有的技术方案可以参考？是否需要进行调整？
为什么要考虑这些问题呢？
项目规模和功能交互会影响框架和工具的选型，比如轻量项目可能 React/Vue 框架比较灵活，大型项目还可以使用 Angular 全家桶。
用户体系会影响系统兼容性的倾向，比如用户受众年龄偏大，则需要考虑使用机型性能可能相对较差、需兼容的机型品牌比较多。
存在多人协作需要考虑完善团队规范，同时尽量使用工具来保证流程规范。
团队技术栈倾向同样影响技术选型，如果有现成的技术方案和项目案例，可以考虑是否符合实际需要，使用团队成员熟练的工具可以避免很多踩坑的过程。
使用一致的代码开发规范
可以使用一些工具来确保代码符合规范：
使用 Eslint 检测代码规范；
使用 Prettier 自动化格式代码；
使用 Git Commit Hooks 拒绝不符合规范的代码提交；
使用流水线检测出不规范的代码，并拒绝合入主干分支；
使用流水线检测出不规范的代码，并拒绝进入发布流程。
制定合适的代码流程规范
一般来说，开发流程会包括：
Git 创建分支过程：分支的命名，是否需要关联需求单或是 BUG 单。
Git 提交代码过程：检查代码是否符合规范，只允许合格的代码（Eslint 规范、单测覆盖率等）进行提交。
分支提交过程：需要进行交叉 Code Review，对方同意后才允许合入代码。
合入主干过程：对代码进行自动化构建和测试，功能正常且符合规范的代码才可合入主干。
代码发布过程：自动拉取主干分支，创建发布分支，对代码进行自动化构建和测试，正常后会开始进入灰度发布流程。
通过自动化的工具我们同样可以确保以上流程按预期进行，很多团队也会使用持续集成（continuous integration，简称 CI）和持续部署（continuous deployment，简称 CD）。CI/CD 在项目中的落地，很多时候会表现为流水线的开发模式。
系统质量的下降
1.1 项目频繁地调整（新增或者更换）开发人员，由于不熟悉项目，每个新加入的小伙伴都可能会埋下新的 Bug； 1.2 系统功能新增和迭代、不断壮大，各个模块间的耦合增加、复杂度增加，如果没法掌握系统的所有细节，很可能牵一发而动全身，产生自己认知以外的 Bug。
为了降低系统的复杂度，当项目发展到一定阶段的时候，会对系统进行局部或是整体的架构调整，比如模块的拆分、各个模块间的依赖解耦、引入新的状态管理工具、重复逻辑进行抽象和封装，等等。
用户反馈问题跟进和定位；
线上 Bug 修复和紧急发布；
处理系统的监控告警，排查异常问题；
4.新功能灰度发布过程，自测、产品验证功能、提测、修复 Bug、灰度发布等各个流程都需要人工操作和主动关注；
为了保证系统质量，需要完善自动化测试能力，包括单元测试、UI 测试、集成测试等；
5.项目成员的调整，需要进行工作的交接、指导对方的工作内容等。
提升系统质量： 项目设计和架构优化
引入新的技术和工具的同时，需要考虑是否能兼容原有设计、团队成员熟悉成本、改造的工作量和预期的效果，选择性价比合适的方案落地。
团队成员增加，沟通成本和对规范的理解出现差异。使用工具（Eslint/Prettier/Git hooks 等）将团队规范进行落地，保证开发过程中使用一致的技术栈、代码规范以及公共物料库（组件库、工具库），降低团队的沟通成本，确保代码的可读性和可维护性。
项目功能模块过多，需要进行模块的拆分和解耦。将一些职责独立的模块进行拆包，使用 monorepo 或是 multirepo 的方式进行管理，模块可自行对技术方案、依赖关系梳理、变更、测试、发布等环节进行闭环，从而降低各个模块间的相互影响，降低系统的复杂度。
项目代码量和文件数的增加，除了进行拆包以外，还需要更新或是优化项目构建工具（使用增量编译、使用 Tree-shaking、升级 Webpack 版本等），减少代码编译、打包等过程的耗时，提升开发效率。
进行自动化测试能力的覆盖，补齐单模块的功能测试、各个模块间的集成测试、UI 组件的界面测试、接口的模拟环境测试、性能测试等。在每次系统发布的时候都可以自动化进行回归测试，避免某个改动影响了其他的功能模块、带来了认知以外的风险，确保系统质量不受影响。
搭建完善的监控体系，在系统灰度、发布、线上运行的过程中可实时观察系统质量，配合告警能力及时发现问题并进行解决，保证系统运行的稳定性。
提升开发效率：项目研发和发布流程优化
项目研发和发布流程优化的核心点在于：将一切需要手动操作和关注的内容自动化。
从主干创建分支，开始进入开发；
开发完成后，补充相关自动化测试（单元测试、集成测试、UI 测试等）；
进行自动化测试的回归，确保系统整体功能能正常运行；
构建代码，部署测试环境，进入产品体验和测试流程；
修复产品体验问题和 Bug，并重复 2~4 步骤；
代码验证完成，进行团队内代码 Review 后，更新主干的分支，并进行代码构建和自动化回归测试；
根据团队 Git 规范（比如 Git Flow 流程），准备发布；
先进行版本灰度，灰度过程中登录监控系统关注各个指标是否有异常；
如果监控系统出现异常，进行问题定位，并在 Bug 修复之后返回到步骤 2；
灰度过程无异常，进行全量发布，发布完后同样观察监控系统是否有异常；
全量发布完成，结束需求单，并将版本进行归存（使用分支或者 git tag）。
持续集成（CI）：目的是让产品可以快速迭代，同时还能保持高质量。
持续部署（CD）：目的是代码在任何时刻都是可部署、可进入生产阶段。
模块耦合严重
模块职责和边界定义不清晰，导致模糊的工作可能存在多个模块内；
各个模块没有统一管理，导致模块在状态变更时需要手动通知相关模块；
模块间的通信方式设计不合理，导致全局事件满天飞、A 模块内直接调用 B 模块等问题，隐藏的引用和事件可能导致内存泄漏。
解局之道：
1.项目规模调整后，对现有架构设计进行分析，如果不再合适则需要进行及时调整和优化。 2. 使用模块解耦的技术方案，将各个模块统一交由框架处理。 3. 梳理各个模块的职责，明确每个模块负责的工作和提供的功能，确定各个模块间的边界和调用方式。
常见考点: • 冒泡 / 快排 - 排序类算法 • LRU / 排列组合 - 应⽤类算法 • 链表 / 堆 / 栈 / 树 / 图 - 数据结构类算法 • 分治 / 动规 - 算法思想 • 深度优先 / ⼴度优先
前端工程化体系实现高效交付
如何进行合理的分工排期
进行工作量评估的过程可以分为三步：
确认技术方案，以及分工合作方式；
拆分具体功能模块，分别进行工作量评估，输出具体的排期时间表；
标注资源依赖情况和协作存在的风险，进行延期风险评估。
当我们确认好技术方案之后，需要针对实现细节拆分具体的功能模块，分别进行工作量的预估和分工排期。否则可能面临分工不明确、接口协议未对齐就匆忙开工、最终因为各种问题而返工等情况。
我们在进行工作量评估的时候，可以精确到半天的工作量预期。对独自开发的项目来说，同样可以通过拆解功能模块这个过程，来思考具体的实现方式，也能提前发现一些可能存在的问题，并相应地进行规避。
提供完整的工作量评估和排期计划表（精确到具体的日期），可以帮助我们有计划地推进项目。在开发过程中，我们可以及时更新计划的执行情况，团队的其他人也可以了解我们的工作情况。
工作量评估和排期计划表的另外一个重要作用，是通过时间线去严格约束我们的工作效率、及时发现问题，并在项目结束后可针对时间维度进行项目复盘。
为了确保项目能按照预期进行，我们还要对可能存在的风险进行分析，提前做好对应的准备措施
最后更新于
这有帮助吗？
