前端基础架构是一系列工具与流程的结合，它是我们在启动一个项目时所需要制定的一系列规范和规划，所以当我们启动一个项目的时候，需要做的事情会很多。
我们将前端的时间段分为三个时期：
- 1.0 时期：才开始工作，我们都是从众多前端框架选择一个框架， 能正常运行即可
- 2.0 时期：选定前端框架 + 完整的构建脚本和构建系统，
- 3.0 时期：选定前端框架 + 完整的构建脚本和构建系统+ 流程规范化。再大一些规模中，我们还需要有自己的design，为了降低成本，我们还需要搭建自己的前端脚手架，一些自己的开发工具和协同工具，于是，重心也会放在构建工具上。
3.1 代码规范：
在设计架构时，我们应从下到上，底层实现最终会影响整个架构
从短期来看，如果一个API能支撑现有的开发，不管它的实现有多么的臃肿，代码质量有多么的不好，只要它能满足当前的业务，那也是可以使用的。但是再长期来说，当业务发生了改变，在这种代码上去扩展，可能我们除了痛苦，还想重新再写，所以我们需要对代码的规范进行一定的约束，才能提高代码的质量和可读性
- 规范代码组织结构
- 统一代码的书写风格
- 组件、函数的命名规范
- 开发工具规范
3.2 代码组织决定应用架构：
为了快速能上手和读懂一个项目，我们需要对代码的组织方式，做以下事情：
- 对README 进行详细的描述：如项目的背景，支持的环境，必要的依赖和搭建方式，项目的安装指南，现实的示列和运行环境是否需要工具，相关的文档链接，相关的开发人员及联系方式，项目目录的描述等等
- 阅读package.json 进行了解：项目使用插件，基础设施，构建脚本
- 浏览 views下 代码的结构，书写的语法及实现的方式等
- 阅读项目下的各个文件，对项目有一个基本的认识
具体的项目规范可以借鉴脚手架标准的文件目录
3.3 统一代码规范，使用lint 规范代码：
开发中，我们可能每天会接收到各个开发写的代码，为了能高效阅读以及符合自己的口味，我们应该统一代码的规范，比如：
- 代码缩进
- 是否以；号结束语句
- 判断是否相等，使用 ==， 避免类型转换
- 函数大括号是否换行
- 字符串是单引号还是双引号的约束
- 开发语法上是使用JSX还是常规方式等
- 其他
3.4 规范命名，提升可读性：
作为开发，可能命令还是比较纠结，因为大部分的命名都是从翻译软件或者其他渠道进行的翻译，并不是特别贴合功能的描述，我们可以通过一些方法使命名更赏心悦目。比如：
- 驼峰命名法： 起源于perl语言，在前端开发中，比较常见使用小驼峰
- 下划线命名：get_type_by_id 这种命名分割方式非常显眼，常用于Python中
- 匈牙利命名法： 属性 + 类型 + 对象描述，如：strFirstName 这种也比较常见
css / Lint规范工具 / html / 组件 的规范等
命名其实网上比较多，我们可以参考阿里的一些命名规范进行开发
可以参考一书《全栈应用开发：精益实践》的风格检测配置
3.5 绘制架构图，减少沟通成本：
在项目中，通过架构图能快速了解到系统的组成部分
在简单前端项目中，架构图可能只是表现不同框架之间的关系，以及不同层级组件的关系，即使不看，我们也能清晰的了解到项目的目录
在复杂的前端项目中，我们使用微前端来设计应用架构时，各应用之间可能存在一定的关联，以及底层的共同依赖，在微应用的前端中，架构图描述的更多是项目的构建过程。
我们可以使用代码生成（graphviz），也可以使用一些画流程图的工具
记录架构决策，在长期项目里，我们需要对架构的一些优化方案进行归档，wiki等，方便追溯，在这个记录中，我们应该有以下内容：
- 标题
- 日期
- 描述抉择相关的状态，包含提议、通过、完成、已弃用、已取代
- 价值中立的、用于描述事实上下文背景
- 应对这种场景的相应决策
- 记录应用决策后产生的结果
看板（圆饼图 / 如：禅道、ones）管理：
可能你现在用不了，但是10年后你再看这个项目，可能开发人员、负责人员不在，但是看板始终还在，它会对你帮助特别大，它包含项目进度、分配的资源，发现问题的作用
3.6 代码提交规范：
【任务卡号】xx & xx: do something 比如：【phodal-001】 ladohp && phodal: update documents
phodal-001: 计量点-#8050 计量点模块的 #8050 bug
ladohp && phodal：bug修复人，-phodal 一般是写代码的人，ladohp是提供思路的人，如果只有一个人修改，那只需要写一个人，这样的目的是方便，一个不在，还可以问另外一个人bug修复的实现方式
update documents： 对解决的这个bug进行描述
但是开源项目用的比较成熟的是：
flx: 修复了某个错误， doc: 只是更改了文档， feat: 添加了一个新功能， perf:改进性能的代码更改， refactor:代码更改，不涉及错误修复也不添加功能， style： 一些css或和格式化，缺少分号的一些报错， 等
其实这些都可以融合在项目中
对比一下我们讨论以上的重要程度：
3.7 测试策略：
在web应用中，有一个很经典的“”测试金字塔” 概念，随着BFF 和前后端的分离，金字塔的概念也发生了变化
金字塔的四个层级分为：
- 单元测试
- 组件测试（快照测试,如react的 virtual DOM快照验证）
- 契约测试、接口测试（服务测试）
- E2E测试(端对端测试、集成测试)
单元测试：需要做以下事情：
- 选定一个单元测试框架： 前端领域，可能你选择的单元测试框架不同，但是区别并不大，用法都是相似的，编写测试的时候，采用往往是三段式风格，given-when-then。假设：一个上下文，指定完成测试所需要的条件； 当：进行一系列操作，所要执行的操作，如点击一个按钮； 那么：得到的可观察的结果，如检测的断言，按钮的隐藏和显示
const nikeName = ''
// given
if (status === true) {
// when
nikeName = 'jason'
// then
window.open('https://')
}
-
创建测试规则
-
制定测试覆盖率的最小值
