React 项目的架构和规范

[EthanLin-TWer]

架构和规范

架构是为了解决什么问题呢？我理解是效率问题。通过一个好的架构，能让你很容易地、具备一致性地理解一个系统，在此基础上快速地、可持续地完成业务功能。它保证的有三点：

• 代码库阅读起来很轻松
• 添加新功能时能很快，理想情况是，仅添加跟业务有关的代码，跟样式、基础设施相关的东西，在一个较为成熟的项目上，应该都比较稳定了
• 在演进过程中，仍然能保持添加功能的速度很快

规范是为了解决什么问题呢？我理解是协作问题。大家一个团队工作，命名习惯不同，代码风格不同，水平参差不同，如何保证整体质量和风格面貌？靠规范呗。

那么架构和规范分别有什么例子呢？

架构

比如目录结构、组件层次、状态管理、副作用管理、路由系统、UX 系统（样式方案）、埋点设计、测试策略、持续集成、构建方式、部署方式等属此列。可以看到，为了开发一个业务功能，底下可能需要这么多基础设施支撑。而架构的目的，就是把尽可能的操作（比如路由、埋点、UX 一致性等）变成常量级别的操作、甚至默认标配的操作，这样才能让你开发起来顺畅，做到只关心业务的部分。

• 目录结构：这个问题与组件层次问题息息相关。在 APP 的场景下，它与 web 又不太一样，APP 往往是首页路由+卡片式堆叠页面。怎么将页面结构映射到目录结构上，怎么保持清晰？是遵循 duck 目录结构设计方式，还是功能式目录结构方式？如果小型项目选择从功能式开始，后续是否有向 duck 结构的迁移路径？需要多少人力？
• 组件层次：是按照 container component -> presentation component 的结构划分？还是不 care？
• 状态管理：React Context、mobx、redux，如何选择？
• 副作用管理：promise 方案？thunk 方案？saga 方案？
• 类型系统：TS。语言层级的类型系统所带来的架构抽象能力
• 路由系统：怎么做到让页面增删变成常量级别的操作？怎么支持多种不同的渲染模式（不卸载/卸载）？
• UX 系统：怎么做到跟 UX 设计保持高度一致？怎么保证只需要常数级别的操作就可以达到这种一致性？如何保证只需要常数级别的操作就可以变更、尝试新的 UX 设计？
• 埋点设计：数据乃产品之本，怎么设计埋点系统，让它对业务代码的侵入性达到最小？怎么保持细粒度埋点的灵活性？如何做到让埋点变成常量级别的操作？埋点数据结构如何设计？统计如何统计？要生成什么报表？报表的生成如何做到常量级别的操作（即不需要人工执行脚本去统计）？
• 测试策略：测哪些？测什么？测多细？由谁测？需要制定可落地的测试策略
• 持续集成：开发方式（分支 or 主干）？自动化测试分别在什么阶段运行？如何让持续集成的配置变成常数级别（而不需要每次换机器都要手动重新搭 CI）？
• 构建方式：用什么工具进行自动化构建？
• 持续部署：部署目的地？部署频率？是否能做到每次提交都进行部署？是否能准备与生产环境尽可能接近的 UAT 环境？

规范

比如代码风格、编程风格、命名风格、提交信息、提交粒度、开发习惯、代码整洁程度、单元测试好坏等属此列。

• 代码风格：Prettier 一键解决
• 编程风格：Eslint 尽量覆盖
• 命名风格：明确基本原则后，写入 README 做宪法 + 术语表
• 提交信息：precommit hook，但没法规范到信息级别，而提交信息是跟提交粒度息息相关的
• 提交粒度：较难以统一的部分。我还是把它放到架构部分去吧
• 开发习惯：自暴自弃的部分。比如 TDD 等
• 代码整洁程度：基本只能用 code review + PR 来规范。这跟开发者是谋生心态还是工匠心态有关，跟组织是技术属性的组织还是政治属性的组织也有关系
• 单元测试好坏：明确好测试的标准后，制定测试策略 + 写入 README 做宪法 + code review 经常反馈

其他的欢迎补充。

[JimmyLv]

补充一个 TS 吧，语言层级的类型和接口系统所带来的架构抽象能力。

[EthanLin-TWer]

完全对。TS 乃必需品