软件开发定律：海勒姆定律（Hyrum's Law）

Posted 竹子-博客-熵减黑客

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件开发定律：海勒姆定律（Hyrum's Law）相关的知识，希望对你有一定的参考价值。

hi，我是熵减，见字如面。

在软件开发中，你是否遇到过这种情况：

你正在开发一个购物车的功能，需要在用户添加商品到购物车时，将商品的信息存储到数据库中。你设计了一个简单的方法，如下所示：

public void addToCart(Item item) 
    // 将商品信息存储到数据库中

在这个方法中，你假设了将商品信息存储到数据库的操作总是会成功，而没有考虑到可能会出现任何错误。然而，在实际情况中，可能会发生各种错误，例如数据库连接失败、写入失败、数据格式不正确等。

如果你只是假设操作总是会成功，并且没有考虑到错误情况，那么你就会遇到海勒姆定律的问题。

什么是海勒姆定律呢？其有什么意义和启示呢，下面我们来具体看一下吧。

什么是海勒姆定律

海勒姆定律（Hyrum\'s Law）是一个软件开发中的概念，它指的是：

“当你依赖于一个 API 的时候，你实际上也依赖于这个 API 的实现细节。”

换句话说，即使一个 API 已经被定义和文档化了，但由于实现的方式可能存在多种选择，所以你在使用这个 API 的时候也要考虑到其实现的细节，而不仅仅是其所声明的功能。

海勒姆定律得名于 Google 工程师 Hyrum Wright，他在一次演讲中提出了这个概念。

Hyrum Wright强调了开发者应该更加注意 API 的实现细节，因为这些细节可能会影响到你的代码在未来的可维护性和稳定性。

海勒姆定的意义

海勒姆定律（Hyrum\'s Law）是一条关于软件开发中 API 使用的规律。其意义在于以下3点：

海勒姆定律的意义在于提醒开发人员，当使用 API 时不仅要考虑其功能，还要了解其实现细节和限制。在软件开发过程中，API 是非常常见的工具，它们可以帮助我们快速实现功能，提高开发效率。

然而，API 的实现方式和细节可能会对代码的行为产生影响，甚至可能导致不可预料的问题。海勒姆定律强调了这一点，提醒开发人员在使用 API 时需要仔细评估其实现细节和稳定性，以避免出现潜在的问题，提高代码的可维护性和稳定性。

此外，海勒姆定律还强调了软件开发的迭代性和变化性。随着软件需求和技术环境的不断变化，API 的实现方式也可能随之发生变化。因此，及时了解并适应 API 的变化，对于保持软件的可维护性和稳定性也非常重要。

一个常见的案例

一个经典的海勒姆定律案例是在多线程环境下使用 Java 的 ArrayList，具体表现为对 ArrayList 的并发修改可能会导致线程安全问题。

下面是一个简单的 Java 代码的示例，演示了对 ArrayList 的并发修改可能导致的线程安全问题：

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ArrayListConcurrencyExample 
    private static List<Integer> list = new ArrayList<>();

    public static void main(String[] args) 
        ExecutorService executorService = Executors.newFixedThreadPool(10);
        for (int i = 0; i < 1000; i++) 
            executorService.submit(() -> list.add(1));
        
        executorService.shutdown();
        while (!executorService.isTerminated())  

        System.out.println("Size of list: " + list.size());

在这个示例中，我们创建了一个固定大小的线程池，然后启动 1000 个线程，每个线程都向 ArrayList 中添加一个整数。最后，我们打印 ArrayList 的大小。

在单线程环境下，这段代码可以正常工作，输出的结果应该为 1000。然而，在多线程环境下，由于 ArrayList 不是线程安全的，可能会出现并发修改问题，导致结果不确定，例如输出的结果可能小于 1000。

要解决这个问题，我们可以使用线程安全的 List 实现，例如使用 Java 的 Vector 或者 Collections.synchronizedList 方法来包装 ArrayList，以保证并发修改时的线程安全性。

海勒姆定律的实践建议

以下是一些有助于在实践中落实海勒姆定律的建议：

  • 了解 API 的文档和规范。 在使用 API 之前，应该先仔细阅读相关文档和规范，了解 API 的功能、用法、限制和可能的问题。

  • 编写健壮的代码。 在使用 API 时，应该编写健壮的代码，考虑到各种可能的错误和异常情况，以保证代码的可靠性和稳定性。

  • 使用稳定的 API 版本。 如果有多个版本的 API 可以选择，应该尽量选择稳定的版本，并尽量避免使用过时或废弃的版本。

  • 进行集成和单元测试。 在使用 API 时，应该编写集成测试和单元测试，验证 API 的正确性和稳定性，并及时修复可能出现的问题。

  • 注意 API 的依赖关系。 在使用 API 时，应该注意其依赖关系，避免引入不必要的依赖，同时也要确保其依赖的组件或库是可靠的和稳定的。

  • 及时处理 API 的变更。 随着软件需求和技术环境的变化，API 的实现方式也可能随之发生变化。在使用 API 时，应该及时了解并适应 API 的变更，以保持软件的可维护性和稳定性。

综上所述，在通过遵循这些实践建议，可以更好地落实海勒姆定律，提高代码的可维护性和稳定性，同时也能够更好地适应软件开发过程中的变化和创新。

海勒姆定律的反模式

除了常见的实践建议外，以下是一些常见的反模式，这些做法不利于落实海勒姆定律：

  • 直接依赖具体实现。 有些开发人员可能会直接依赖具体实现，而忽略了 API 的规范和约定。这种做法会使代码与实现紧密耦合，增加了代码的脆弱性和难以维护性。

  • 忽略 API 的限制和异常。 有些开发人员可能会忽略 API 的限制和异常情况，而直接假定 API 总是能够正常工作。这种做法会增加代码的不确定性和出错概率，导致代码的不可靠性和难以维护性。

  • 直接使用底层库或组件。 有些开发人员可能会直接使用底层库或组件，而忽略了 API 的规范和封装。这种做法会使代码与底层实现紧密耦合，增加了代码的复杂性和难以维护性。

  • 忽略 API 的版本变更。 有些开发人员可能会忽略 API 的版本变更，而仍然使用过时或废弃的版本。这种做法会增加代码的不兼容性和难以维护性，同时也会使代码与技术发展脱节。

  • 不合理地添加或删除依赖。 有些开发人员可能会不合理地添加或删除依赖，而忽略了 API 的依赖关系和稳定性。这种做法会使代码的依赖关系变得混乱和不可控，增加了代码的复杂性和难以维护性。

综上所述，避免这些常见的反模式，能够更好地落实海勒姆定律，提高代码的可维护性和稳定性，同时也能够更好地适应软件开发过程中的变化和创新。

最后

海勒姆定律是一个非常重要的原则。其告诉我们，在处理复杂系统时，我们不能只关注系统的主要功能，还需要考虑系统中的各种依赖关系和副作用。

如果我们只是假设一切都是正确的，并没有考虑到系统的各种依赖关系和副作用，那么就会遇到各种意外和问题，这可能会导致系统崩溃或出现其他严重问题。

在编写代码时，我们应该注意避免海勒姆定律的陷阱，并考虑使用一些最佳实践来确保代码的稳定性和可靠性。

总之，海勒姆定律的重要性不能被忽视。对于开发人员来说，了解这个原则，并在实践中应用它，将有助于提高代码的质量和稳定性，从而为用户提供更好的体验。

阅读，思考，练习，分享，日日不断之功。

嗯，写完了。

新的一天，加油哦 (ง •̀_•́)ง

Github最火项目：程序员必读职场15大定律和7大原则


大家估计有个越来越深的感受，就是说只做写代码的码农太局限了，现在这个环境，大家都想往上走当领导，除了升职加薪，其实也是实现了阶层的跨越。



定律

阿姆达尔定律(Amdahl's Law)

布鲁克定律(Brooks's Law)

康威定律(Conway's Law)

侯世达定律(Hofstadter's Law)

阿玛拉定律的“炒作周期”(The Hype Cycle & Amara's Law)

海勒姆定律(Hyrum's Law)

摩尔定律(Moore's Law)

帕金森定律(Parkinson's Law)

普特定律(Putt's Law)

泰斯勒定律(复杂性守恒定律,Tesler's Law)

抽象化漏洞定律(The Law of Leaky Abstractions)

琐碎定律(The Law of Triviality)

Unix哲学(The Unix Philosophy)

Spotify模型(The Spotify Model)

Wadler定律(Wadler's Law)


原则

鲁棒性原则(The Robustness Principle,Postel's Law)

SOLID

单一职责原则(The Single Responsibility Principle)

开放封闭原则(The Open/Closed Principle)

李氏替换原则(The Liskov Substitution Principle)

接口分离原则(The Interface Segregation Principle)

依赖倒置原则(The Dependency Inversion Principle)


整体还是建议大家看一下的，对于思维的打开很有帮助，太多就不逐个分析了，我就展开讲一下布鲁克定律吧。


维基百科中对此定律的解读是：将人力资源添加到一个后期软件开发项目中会使它更晚。 


啥意思呢？通俗点说就是：更多的人反而会让项目延迟。这乍看可能是违背常理的，但它基本上是正确的且经过验证的。


以上是关于软件开发定律：海勒姆定律（Hyrum's Law）的主要内容，如果未能解决你的问题，请参考以下文章

Conway's law(康威定律)

摩尔定律(Moore's Law)

康威定律Conway's law 20190710

里特定律 - Little‘s Law

里特定律 - Little‘s Law

里特定律 - Little‘s Law