软件开发定律:海勒姆定律(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