面向时空

面向时空编程需要开发者以空间结构管理和时间流程规划的姿态去理解软件开发的本质。

另一方面，面向时空编程需要兼容和解释已有的经典理论，将经典理论纳入时空框架中而不产生矛盾。这要帮助我们从一个更高更全面的维度去理解这些理论的本质，总结概括杂乱的理论商品，减少选择困难。

面向时空编程需要走到实践中去，提出具体的实践方案，让理论变得可行。

软件时空观

分析设计一个程序系统，可以从空间结构和时间流程两个大方向入手，先看空间结构，然后看结构之间的交互流程。

结构

当下的软件系统在空间形态上有两个明显的边界，一个是进程边界，一个是主机边界，使得空间被划分成 3 层结构。

进程内

• 模块拆分
• 依赖管理，作用域交互、依赖倒置 组件耦合原则

当设计从类级别上升到组件级别时，需要遵循一套新的原则来控制组件间的依赖关系。

ADP：无环依赖原则

组件依赖图中不应出现环路。如果 A 依赖 B，B 依赖 C，那么 C 绝对不能依赖 A。循环依赖会导致组件无法独立测试和发布，任何变更都可能产生连锁反应。

解决循环依赖的方法通常是引入新的抽象组件，或者通过依赖倒置打破原有的依赖链条。

SDP：稳定依赖原则

依赖应该指向更稳定的方向。不稳定的组件（易变的）应该依赖稳定的组件（不易变的）。如果一个稳定的组件依赖了一个易变的组件，那么每次易变组件的修改都会迫使稳定组件跟着变化，这违背了稳定性的初衷。

组件的稳定性可以通过"入度依赖数"和"出度依赖数"来衡量：入度越大（被越多组件依赖）、出度越小（依赖越少组件），则组件越稳定。

SAP：稳定抽象原则

一个组件越稳定，它就应该越抽象。稳定的组件被广泛依赖，不应该频繁变化，因此应该是抽象的接口或基类；不稳定的组件可以频繁变化，因此可以是具体的实现。

这一原则与 SDP 结合，形成了组件设计的指导方针：向着"稳定且抽象"的方向努力，避免"不稳定且具体"的组件。

• 状态管理，生命周期、纯函数

状态管理，生命周期对齐，状态同步，状态分步加载，流式加载，分页加载 配置和配置文件管理，命令行，环境变量，配置中心，配置接口 依赖管理，正交性原则

通过接口隔离降低耦合、通过策略模式消除大量 if-else、通过依赖注入实现可测试性。

本机上

• 文件管理
• 微服务治理
• 数据与配置分离

主机间

• 分布式锁
• 通信代理

涉及跨进程通信，引入外部 IO，可能产生失败；设计跨主机通信，引入网络延迟，增加了程序阻塞。

流程

时间是基于空间结构的，流程研究的是空间如何随着时间的改变而发生变化。

以前的开发者仅仅关注单进程中的时间流程，后来逐步扩展到整个集群架构层级的时间流程，

当我们将整个软件开发生命周期纳入设计，我们发现开发、测试、运维人员属于空间结构中的不同的组成，在时间流程上存在空窗，开发在编写程序阶段，测试人员和运维人员的时间是被阻塞和浪费的，因此出现了 DevOps 将测试和运维的任务在时间维度上向开发人员折叠

需求分析 -> 开发设计 -> 测试评估 -> 运维监控
    ↑                                ↓
        <-          <-         <-

生命周期中有不同的角色分工 刚好对应着互联网公司的 4 个岗位，产品、开发、测试、运维，

是一个简化的长时间的时间迭代维度模型，初次编写一个软件的耗时仅占据整个软件的生命周期的一小部分，在设计软件的时候就应该站在整个软件的生命周期的全过程去考虑。