海拉姆定律(Hyrum's Law)

[bingoohuang]

海拉姆定律(Hyrum's Law)

在看Building a high performance JSON parser时，里面提到海拉姆定律 Hyrum's Law

An observation on Software Engineering 关于软件工程的一点看法
Put succinctly, the observation is this:

简单地说，观察结果是:

With a sufficient number of users of an API, 如果一个 API 有足够数量的用户,
it does not matter what you promise in the contract: 你在合同里承诺什么并不重要:
all observable behaviors of your system 你系统的所有可观察的行为
will be depended on by somebody. 将会被某些人所依赖
Over the past couple years of doing low-level infrastructure migrations in one of the most complex software systems on the planet, I’ve made some observations about the differences between an interface and its implementations. We typically think of the interface as an abstraction for interacting with a system (like the steering wheel and pedals in a car), and the implementation as the way the system does its work (wheels and an engine). This is useful for a number of reasons, foremost among them that most useful systems rapidly become too complex for a single individual or group to completely understand, and abstractions are essential to managing that complexity.

在过去的几年中，我在地球上最复杂的软件系统之一中进行了低层次的基础设施迁移，我对接口与其实现之间的区别做了一些观察。 我们通常认为接口是与系统交互的抽象(比如汽车的方向盘和踏板) ，而实现是系统工作的方式(轮子和引擎)。 这是有用的，原因有很多，其中最重要的是，大多数有用的系统很快变得过于复杂，以至于单个个人或群体无法完全理解，而抽象对于管理这种复杂性是必不可少的。

Defining the correct level of abstraction is a completely separate discussion (see Mythical Man-Month), but we like to think that once an abstraction is defined, it is concrete. In other words, an interface should theoretically provide a clear separation between consumers of a system and its implementers. In practice, this theory breaks down as the use of a system grows and its users start to rely upon implementation details intentionally exposed through the interface, or which they divine through regular use. Spolsky’s “Law of Leaky Abstractions” embodies consumers’ reliance upon internal implementation details.

定义正确的抽象级别是一个完全独立的讨论(参见《人月神话》) ，但是我们倾向于认为一旦定义了抽象，它就是具体的。 换句话说，接口在理论上应该在系统的使用者和实现者之间提供一个清晰的分离。 在实践中，随着系统使用的增加，用户开始依赖于通过界面有意公开的实现细节，或者通过经常使用来预测，这个理论就会崩溃。 Spolsky 的“抽象漏洞法则”体现了消费者对内部实现细节的依赖。

Taken to its logical extreme, this leads to the following observation, colloquially referred to as “The Law of Implicit Interfaces”: Given enough use, there is no such thing as a private implementation. That is, if an interface has enough consumers, they will collectively depend on every aspect of the implementation, intentionally or not. This effect serves to constrain changes to the implementation, which must now conform to both the explicitly documented interface, as well as the implicit interface captured by usage. We often refer to this phenomenon as "bug-for-bug compatibility."

从逻辑的极端来看，这导致了下面的观察，俗称“隐式接口法则” : 只要有足够的使用，就不存在所谓的私有实现。 也就是说，如果一个接口有足够多的使用者，那么他们就会有意无意地依赖于实现的每个方面。 这种效果可以将更改约束到实现，现在实现必须既符合显式文档化的接口，又符合用法捕获的隐式接口。 我们经常将这种现象称为“ bug-for-bug 兼容性”

The creation of the implicit interface usually happens gradually, and interface consumers generally aren’t aware as it’s happening. For example, an interface may make no guarantees about performance, yet consumers often come to expect a certain level of performance from its implementation. Those expectations become part of the implicit interface to a system, and changes to the system must maintain these performance characteristics to continue functioning for its consumers.

隐式接口的创建通常是逐步进行的，而接口使用者通常不会察觉到这种情况的发生。 例如，接口可能不能保证性能，但是使用者通常希望从其实现中得到一定程度的性能。 这些期望成为系统的隐式接口的一部分，对系统的更改必须保持这些性能特征，以便为其使用者继续运行。

Not all consumers depend upon the same implicit interface, but given enough consumers, the implicit interface will eventually exactly match the implementation. At this point, the interface has evaporated: the implementation has become the interface, and any changes to it will violate consumer expectations. With a bit of luck, widespread, comprehensive, and automated testing can detect these new expectations but not ameliorate them.

并非所有消费者都依赖于相同的隐式接口，但是如果有足够的消费者，隐式接口最终将与实现完全匹配。 在这一点上，接口已经蒸发: 实现已经变成了接口，对它的任何更改都将违背消费者的期望。 幸运的是，广泛、全面和自动化的测试可以检测到这些新的期望，但不能改善它们。

Implicit interfaces result from the organic growth of large systems, and while we may wish the problem did not exist, designers and engineers would be wise to consider it when building and maintaining complex systems. So be aware of how the implicit interface constrains your system design and evolution, and know that for any reasonably popular system, the interface reaches much deeper than you think.

隐式接口是大型系统有机生长的结果，虽然我们可能希望这个问题不存在，但在构建和维护复杂系统时，设计师和工程师应该明智地考虑这个问题。 因此，要注意隐式接口如何限制您的系统设计和演变，并且要知道，对于任何相当流行的系统，接口比您想象的要深入得多。

Who's Hyrum?
谁是希拉姆？
I'm a Software Engineer at Google, working on large-scale code change tooling and infrastructure. Prior to that, I spent five years improving Google's core C++ libraries. The above observation grew out of experiences when even the simplest library change caused failures in some far off system.

我是 Google 的一名软件工程师，致力于大规模的代码更改工具和基础设施。 在此之前，我花了五年时间改进谷歌的核心 c + + 库。 上述观察来自于一些经验，即使是最简单的库更改也会导致一些遥远系统的失败。

While I may have made the observation, credit goes to Titus Winters for actually naming it as "Hyrum's Law" and popularizing the concept more broadly.

虽然我可能已经提出了观察，归功于泰特斯温特斯实际上命名为“ Hyrum 的法律”和普及的概念更广泛。

里面进而提到抽象漏洞法则

“抽象泄漏”是软件开发时，本应隐藏实现细节的抽象化不可避免地暴露出底层细节与局限性。抽象泄露是棘手的问题，因为抽象化本来目的就是向用户隐藏不必要公开的细节。

“ All non-trivial abstractions, to some degree, are leaky.所有重大的抽象机制在某种程度上都是有漏洞的. ”