软件工程实践 - 规范与执行策略比设计思想更重要

[TotooriaHyperion]

需要思考的问题

1. MV* 设计的根本目的，都是将 M 和 V 解耦，那么在 MVVM 中，VM 层应该包含哪些内容，VM 层应该是怎样一个形态，如何构造 VM 层？
   1. 希望 Model 尽可能是抽象，稳定，可测试的。
   2. 希望 View 层是明显没有 bug 的。
   3. 希望 VM 层能精确描述数据的订阅关系，且实现 View 与 Model 互相无感知
      1. 业务逻辑根据抽象程度决定在 Model/VM/View，抽象逻辑在 Model 通用业务逻辑在 VM 具体视图逻辑在 View。
      2. 简单逻辑由 View 层初步实现，若复杂度较高，则将 View 拆分为 Container 和 Presentation 对于 React 来说，此处 Container 使用 hooks 实现。
      3. 根据实际需要，可将通用逻辑从 View 中提取至 VM 将已确定的抽象逻辑从 VM 中提取至 Model。
   4. 希望 Module = VM(Model + View) 是可以独立运行的(分形 Model + 分形 View + 可组合 VM)。
   5. 于是 View = VM binding(Container/hooks) + pureView(Presentation)。
   6. 于是 DataFlow = VM binding + Context。
   7. Context 代表 API 提供 Input 和 Output 的类型约束。
   8. 依赖了 Context 的组件的运行，建立在 Context.Provider 的基础上。
   9. 而 ContextProvider 组件(eg: di/services/xxx/bindings.tsx -> XxxProvider)提供从 token -> API 的实现
2. 插件化下，如何实现各个部分的可替换？
   1. 什么是不可替换的？
      1. Context 及其 API 所提供的类型约束。
      2. ContainerProvider - 提供依赖注入的 Container 给下面的可替换部分。
   2. 什么是可替换的？
      1. VM：ContextProvider 从 token -> API 的实现
      2. View
      3. Model
   3. 在哪里，如何替换？
      1. useInjectXXX - 动态依赖注入

规范与执行策略比设计思想更重要

• 光有思想没有规范不能指导开发。
• Spring 的成功，本身不是它框架有多好，思想有多先进。而是对实现的强约束确保了制度层面的代码质量的保障。
• 制度层面的保障也同时确保了 Code Review 的意义。
  1. 只有粒度够细，Code Review 才能在业务逻辑质量上有一定意义。
  2. 只有约束实现，Code Review 才能在制度层面保证代码质量。
• 最重要的是基于思想的规范，而不是思想本身。
• 有了思想，没有合理的规范和执行策略，就没法坚持下来。