API 管理：从变更到生命周期
1. API 变更管理
在 API 开发中，发布代码后，更改接口模型往往需要相应的代码变更。通常，我们希望避免破坏依赖于我们 API 的客户端。不过在实际操作中，你可能会发现，对某些客户端的可靠性关注程度会低于其他客户端。例如，一个会破坏很少使用的第三方应用程序的 API 变更，相比破坏组织面向客户的移动应用程序的变更，更具合理性。
关于 API 合适的耦合程度以及何时应进行变更，并没有绝对的答案。如果松散耦合没有成本，我们都会选择它，但长期价值伴随着短期成本，构建能很好应对变更的 API 需要前期投入精力。你需要尽早决定变更成本以及你认为所需的 API 类型。
需要注意的是，低可变更性与高代码变更成本相结合，意味着持续改进 API 模型并非现实的策略。在最好的情况下，这意味着你的持续改进将仅限于不破坏客户端的接口模型变更。在这种情况下，在 API 被大量使用之前，采用前期进行大设计的方法来设计接口模型是个不错的选择。
1.1 “前期大设计”是否是反模式？
如果你熟悉敏捷宣言，可能会想我们这里描述的是否是敏捷实践者试图避免的“前期大设计”（BDUF）反模式。在软件工程中，避免冗长的设计阶段很有意义，因为这意味着我们可以基于不断增长的实现，通过持续的设计努力进行短周期的变更。这种迭代式的产品设计方法提供了更大的适应性空间，因此避免 BDUF 是个好主意。
然而，对于 API 而言，以这种方式引入迭代式变更可能很困难，因为对接口进行变更会对使用它的应用程序代码产生连锁反应。我们并不是建议提前设计好 API 的所有细节，但就像建筑物的架构或大理石雕像的构图一样，API 一旦创建（并发布），往
