时间

针对时间部分，书中提出了一条重要的规则——海勒姆定律：

海勒姆定律
当一个API有足够多的用户时，在约定中你的承诺已经不重要：所有在你系统内被观察到的行为都会被一些用户所依赖。

该定律体现出软件开发过程中时间和规模的权衡。长时间不作任何更新可能会保证一段时间内所有相关业务的稳健运行，但是无法确保可持续性和效率。因此当不得不面临重构时，软件相关的各种服务已经被吸纳到各种业务中，从而使软件的优化甚至重构具有诸多潜在风险，即“牵一发而动全身”，很可能会导致很多隐藏问题、或触犯到某一用户群体的核心诉求。因此只有可靠地一致保持这种持续最新的状态，才是其长期可持续性的根本 。

其实软件工程的最终目标不是“没有变化”，反而是能一致稳定持续、有迹可循的变化，并保证这种变化能持续提升效率且不会造成过多潜在危害。

规模

针对一个代码库，当能做出任何安全变更，且代码库的生命周期内都可以这样做，则组织的这个代码库时具有可持续性的。另外需要考虑的是，随着时间的推进，代码库的维护和更新是否会带来成本的非线性增长，如果是的则有可能该代码库上的运营是不可扩展的。

另外，随着组织的扩张，不得不面临的问题就是，要思考如何以一种可扩展的方式实现开发、迭代和扩展。或许“减小扰动”是一个方法，即基础设施团队必须自己完成将内部用户迁移到新版本的工作，或以向后兼容的方式进行适当的更新 。且部署一个专家组统一解决版本更新或许比把该项工作分配给负责该业务块的团队来做要更加合适。另外，采用合适数量的分支管理也是一个合适的选择。

每次更新必然都是需要进行测试的，因此这里也引入“碧昂斯规则”：

碧昂斯规则
如果持续集成(CI)系统中的自动化测试并未发现这个问题，那就不应该由负责基础设施的团队承担责任(如果你喜欢它，你应该对它进行CI测试)

随着不断升级，规模化可以逐渐转变为优势：

• 自动化：每个人都具有更高的效率
• 整合/一致性：低层次变化限制在一定的问题范围内
• 专业知识：少数人可以做的更多

自然的，在一个大多数代码都经过多次升级的生态系统中，它不再依赖于底层实现的细微差别，反而取决于语言/操作系统所保证的实际抽象。

此外，专业知识与共享也在组织规模化上提供了巨大的价值。

权衡

在权衡部分，重点介绍两点：

• 左移思想：尽可能早的发现问题并解决，最好在提交之前就通过静态分析和代码评审捕获缺陷，在开发早期就强调质量、可靠性和安全性，并积极设计相应的工具和实践方案以提供保障。
• 决策与时间：要确保每一个决策的背后都要有合理的解释支撑，要么是因为需求必须这么做、要么是该决策是基于当前所有证据的最佳选择。当然，有时候仍然会不可预料地出现资源消费失控局面 (Jevons 悖论)。

开发作业流时间线
一个完整的开发作业流时间线包括这几个阶段：概念(Concept)、设计(Design)、开发(Development)、测试(Testing)、提交(Commit)、整合(Integration)、产出(Production)。

另外，进行数据驱动的决策是很重要的一个点，因为时间不仅会触发技术依赖和软件系统的变化，还会触发用于驱动决策的数据的变化。