海勒姆法则(Hyrum‘s Law)

在对于共享代码库的足够大的用户群中，有人会依赖于你代码的任何可能特性——包括你的漏洞。

摘要

Hyrum’s Law，海勒姆法则，是软件开发中的一个原则，它的核心思想是：当一个接口被足够数量的用户使用时，不论你在接口合约中做了什么承诺，都会有相应数量的情况出现，你会发现自己对某些人的期望是错误的。

换句话说，Hyrum的法则强调了当越来越多的开发人员和系统依赖于特定接口（如API或库）时，它们可能依赖于接口所未明确保证的某些行为或假设。当对接口进行更改时，即使是看似微小或无关紧要的更改，也可能意外地破坏依赖于该接口的代码。

该法则强调了围绕广泛使用的接口形成的隐含合约和假设。当一个接口被广泛采用时，对其期望和依赖变得更加多样化和难以预测。它不仅仅关乎接口在文档中明确说明的内容，还涉及用户根据对接口行为的理解所做的意外副作用和假设。

海勒姆法则提醒软件开发人员要注意对公共接口进行更改可能产生的影响，因为用户可能依赖于未明确指定的行为。它强调了在更改这些接口时需要进行清晰的沟通、文档化和慎重考虑，以减少中断和意外后果。

Simply put

Hyrum’s Law is a principle in software development that states: “With a sufficient number of users of an interface, it doesn’t matter what you promised in the interface contract—you’re going to get a correspondingly sufficient number of instances where you’re wrong about what someone expects.”

In simpler terms, Hyrum’s Law highlights the idea that as more developers and systems start depending on a particular interface (such as an API or a library), they may rely on certain behaviors or assumptions that are not explicitly guaranteed by that interface. When changes are made to the interface, even seemingly small or insignificant ones, it can unintentionally break the code that relies on it.

The law emphasizes the implicit contracts and assumptions that develop around widely used interfaces. It suggests that when an interface is widely adopted, the expectations and dependencies around it become more diverse and difficult to predict. It’s not just about what is explicitly documented in the interface, but also about the unintentional side effects and assumptions users make based on their understanding of how the interface behaves.

Hyrum’s Law serves as a reminder to software developers to be mindful of the impact any changes to public interfaces can have, as users may rely on behaviors that were not explicitly specified. It emphasizes the need for clear communication, documentation, and careful consideration when making changes to these interfaces to minimize disruptions and unexpected consequences.

On the other hand

Once upon a time, there was a popular social media platform called “Socialville” that had millions of users worldwide. Socialville had an API that allowed developers to build applications and integrate with the platform.

A talented developer named Alice discovered this API and saw its potential for creating a unique photo-sharing application. She began working tirelessly, pouring her heart and soul into developing this app called “Snap n’ Share.” Alice carefully studied the API documentation, understanding its limitations and promised behaviors.

Snap n’ Share became a tremendous success, quickly gaining millions of users. People loved the app’s features and its seamless integration with Socialville. However, as time went on, more and more developers noticed this success and started using the same API to build their applications.

As the user base of the API grew exponentially, so did the expectations and assumptions around its behaviors. Developers began depending on certain undocumented quirks and behaviors that were not explicitly guaranteed by the API contract. They built their applications around these implicit expectations, adding their unique touch to the Socialville ecosystem.

Meanwhile, the development team at Socialville recognized the need for some API improvements. They decided to make a few updates to enhance the security and performance of the API. While these updates were necessary, the team failed to consider the unintended consequences that these changes might have on the applications relying on their API.

When the updates were rolled out, chaos ensued. Snap n’ Share, along with numerous other applications, started experiencing unexpected errors. Features that were once reliable suddenly broke, leaving users frustrated and disappointed. The developers scrambled to fix their applications, but they were caught completely off guard by the changes to the API.

Alice, the creator of Snap n’ Share, was devastated. She had spent countless hours crafting her app, only to have it crippled by the unforeseen consequences of API updates. She realized firsthand the truth of Hyrum’s Law – even if you promise certain behaviors in the interface contract, with a sufficient number of users, there will always be instances where you’re wrong about what someone expects.

After a period of recovery and reflection, Alice decided to rebuild Snap n’ Share, this time with a more resilient architecture. She carefully reevaluated her dependencies on the API and found ways to create fallback mechanisms and handle unexpected changes gracefully. This time, she was mindful of the implicit assumptions and limitations that come with relying on a widely used interface.

Alice’s rebuilt app became a hit once again, with users appreciating its stability and adaptability. She learned a valuable lesson from Hyrum’s Law – the importance of clear communication, documentation, and careful consideration when making changes to public interfaces.

And so, Alice’s story became an inspiration for many developers who understood the delicate balance between promised interface behaviors and the unforeseen expectations that arise from widespread usage. They embraced the principles of Hyrum’s Law, ensuring that their applications remained resilient, even in the face of evolving interfaces.