设计项目需要关注的重点：
- 技术方案设计和选型
- 多人协作和团队规范的制订
技术方案设计和选型
从0开始搭建项目，需要考虑一下技术选型：
- 前端框架和脚手架
- 状态管理工具
- 路由管理
- 代码构建和编译方案
需要基于项目定位(To B还是To C)， 用户量体系，项目复杂度因素，进行技术方案的设计
技术选型的影响因素
一般来说从头开始搭建前端项目：
- 项目规模如何，功能交互是否复杂，面向哪些用户
- 是否存在多人协作？团队规模大概是怎样的？
- 团队成员技术栈如何？对新技术的接受程度怎么样？
- 还是否有现有技术方案可以参考？是否需要进行调整？
为什么要考虑这些问题？
- 项目规模和功能交互会影响框架和工具的选型轻量项目可能react/Vue框架比较灵活，大型项目还可使用Angular全家桶。
- 用户体系会影响系统兼容性的倾向，比如用户受众年龄偏大，则需要考虑使用机型性能可能相对较差，需要兼容的机型品牌比较多。
- 存在多人协作需要考虑完善团队规范，同时尽量使用工具来保证流程规范。
- 团队技术栈倾向同样影响技术选型，如果有县城的技术方案和项目安利，可以考虑是否符合实际需要，是团队成员熟练的工具可以避免很
前端框架和工具选型
对于前端框架和工具你的使用，项目面临两个选择：
- 使用开源/现有框架
- 造轮子
使用开源的好处是，它们有完整详细文档，丰富的社区资源。在遇到问题的时候也能通过issues和Stack Overflow来查找。
前端发展到现在，几大框架的之间的差距越来越小，目前主流的三大框架包括 Angular、React 和 Vue可以进行选型和对比：
| 框架 | 优势 | 不足 |
|---|
| Angular | 提供完整的开发规范和解决方案，解决了多人协作、大型应用的痛点 | 基于大型复杂项目设计，解决方案大而全导致相对笨重设计和使用的概念很多（如依赖注入/注入器/令牌、指令、模块化、AOT 等），入门成本较大 |
| React | 概念较少，对前端编码侵入较少，开发者只需要掌握 Javascript 便可实现大多数功能框架（库）轻量，可灵活搭配各种状态管理工具、脚手架等进行开发 | 对于大型复杂项目，需要自行搭配其他配套工具来解决 |
| Vue | 对新人友好、文档和社区较完善框架（库）轻量，可灵活搭配各种工具进行开发，官方也提供完整的全家桶解决方案 | 如指令和语法糖有一定的概念门槛对于大型复杂项目，需要自行搭配其他配套工具来解决 |
除了热门框架，有能力的团队可以选择贴合自身项目需要，相对小众的框架和工具，甚至可以自行研发合适自己的。
如果想要做自己的框架，尤其是想要在业务中尝试使用，需要万分谨慎，除了需要贴合业务实际需要，更要具备足够的责任感，需要提供友好的文档和API给其他人，不然对项目的维护，新加入的成员来说，会带来毁灭性的开发体验。
技术选型没有标准答案，很多时候我们还需要结合项目现状，选择适合团队使用的技术栈。
多人协作和团队规范
相比项目的搭建和快速上线，项目的维护永远是程序员的大头。搭建一套代码合流程规范，不知将规范写的淋漓尽致，更是需要使用流程化的工具来确保大家遵守规范。
使用一直的代码开发规范
好的编码习惯很重要，语义化的变量命名，适当的注释，都会对代码的可读性有很大的提升。但是每个人习惯都不一样，所以我们需要有统一的代码规范。
可以是使用一些工具来确保代码符合规范：
- 使用 Eslint 检测代码规范；
- 使用 Prettier 自动化格式代码；
- 使用 Git Commit Hooks 拒绝不符合规范的代码提交；
- 使用流水线检测出不规范的代码，并拒绝合入主干分支；
- 使用流水线检测出不规范的代码，并拒绝进入发布流程。
制定合适的代码流程规范
一般来说开发流程会包括：
- git 创建分支过程 ： 分支命名，是否需要关键需要单或者bug单
- git提交代码过程 ： 检查代码是否符合规范，只允许合格代码进行提交。
- 分支提交过程：需要进行交叉Code Review ， 对方同意后才允许合入代码
- 合入主干过程：对代码进行自动化构建和测试，功能正常且符合规范的代码才可以合并主干、
- 代码发布过程：自动拉去主干分支，创建发布分支，对代码进行自动化构建和测试，正常后会开始进入灰度发布流程。
通过自动化的工具我们同样可以确保以上流程按预期进行，很多团队也会使用持续继承(CI)和持续部署(CD)。CI/CD在项目中的落地，很多时候会表现为流水线的开发模式。建立完成的 CI/CD 流水线，除了可以按照规范约束每次代码提交的质量，还可以有效地提高效率。越是大规模的团队越能体会搭配CI/CD带来的便利。