最近看到了一篇文章 Hyrum’s Law，觉得非常有意思，感觉应该翻译一下，也顺带夹杂点自己的理解。
这篇文章主要是一位在底层架构上面工作多年的一位资深工程师观察到的一个现象，简单来说，就是：
当一个 API 有足够的用户的时候，在约定中你承诺的什么都无所谓，所有在你系统里面被观察到的行为都会被一些用户直接依赖。
在详细解释这个之前，我们可以先来说说程序设计里面非常重要的两个东西，接口和实现。通常在一个系统里面，接口就是一个于系统交互的抽象，譬如汽车的方向盘和油门，刹车这些（我们通过这些来控制汽车，与汽车交互），而实现则是这个系统工作的一种方式，譬如汽车的轮子和引擎（汽车实际是通过这些来工作的）。区分接口和实现的好处是非常明显的，当一个系统快速迭代，变得越来越复杂和难以理解的时候，抽象能非常好的帮助我们管理这些复杂性。
关于如何定义不同层级的抽象，可以参考其他的文章，譬如经典的《人月神话》，这里我们可以假设，如果一个抽象被定义好了，那么它其实就是有形具体了。也就是说，一个接口在理论上面需要清晰的将系统的使用者和该系统的实现隔离开。但现实往往是残酷的，当这个系统开始逐渐膨胀，一些用户开始依赖一些通过接口暴露出的内部的实现细节，这条理论就被打破了。
著名的 Joe 有一篇文章 Law of Leaky Abstractions，里面就列举了很多这样的例子，一个就是我们常用的 SQL。SQL 其实可以看做是一个对数据库操作的抽象，我们只需要通过 SQL 语句就能非常方便的查询数据，而不用去为数据库写特定的执行步骤。但是，有时候，我们会发现，一些 SQL 语句明显会比其他的运行的要慢，譬如 where a=b and b=c and a=c 可能就比 where a=b and b=c 要快不少，为了搞明白，我们就必须深入细节，去看相关的 query plan。这时候，我们其实就已经打破了 SQL 这层的抽象，因为我们必须要去了解底层实际的执行方式了。
只要细致观察，通常我们都会发现一个有趣的现象，原作者将其称为 “The Law of Implicit Interfaces” ，也就是说，只要一个系统有足够的使用者，那么就没有啥私有实现这个说法了，用户会开始依赖实现的任何方面，无论是内部的还是外部的。这样，实现的一些随意变更也会被限制了，因为现在我们不光要保证公开的有文档的接口，同时也要考虑已经被使用的内部的隐示接口。原作者将这个现象称为 “bug-for-bug compatibility”。
隐示接口的产生是一个缓慢的过程，以至于接口的使用者通常都不会注意到它已经出现了。例如，一个接口不保证任何性能，但使用者通过它的实现，预期了它的性能能达到哪一个层级。这个期望变成了系统的一个隐示接口，后续改系统的任何改动都需要保证这个接口的性能特性，从而能让用户正常工作。
隐示接口来自于大型系统的增长，当然我们其实并不想让这个问题出现，这就要求我们在构建和维护复杂系统的时候思考的更全面一点。我们需要意识到，隐示接口会限制我们系统的设计和发展，对于任何的流行系统，接口的水比我们想的还深。
