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 的依赖关系和稳定性。这种做法会使代码的依赖关系变得混乱和不可控,增加了代码的复杂性和难以维护性。

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

最后

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

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

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

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


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

嗯,写完了。

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

软件开发定律:海勒姆定律(Hyrum's Law)的更多相关文章

  1. 敏捷软件开发VS传统软件工程

    敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同 ...

  2. Atitit.软件开发的三层结构isv金字塔模型

    Atitit.软件开发的三层结构isv金字塔模型 第一层,Implements 层,着重与功能的实现.. 第二次,spec层,理论层,设计规范,接口,等.流程.方法论 顶层,val层,价值观层,原则, ...

  3. Atitit.软件开发的几大规则,法则,与原则Principle v3

    Atitit.软件开发的几大规则,法则,与原则Principle  v31.1. 修改历史22. 设计模式六大原则22.1. 设计模式六大原则(1):单一职责原则22.2. 设计模式六大原则(2):里 ...

  4. 软件开发的一些"心法"

    从事软件开发也有好几年了,和一开始那个懵懵懂懂的小菜鸟相比,自己也感觉到了一些变化. 也许是熟能生巧, 趟过很多坑,但核心的绝不是这些细节的东西. 打个比方,如果说对某种语言的特性和技巧的掌握属于身法 ...

  5. 敏捷软件开发 VS. 传统软件工程

    敏捷软件开发 VS. 传统软件工程 软件工程这一术语1968年被提出,之后美国软件工程专家巴利·玻姆对十多年间研究软件工程的专家学者们提出的一些准则与信条,于1983年对提出软件工程的七条基本定理,将 ...

  6. 敏捷软件开发vs传统软件开发

    摘要 本文介绍了传统软件开发(着重介绍了传统软件开发中常用的瀑布模型)和敏捷软件开发,以及敏捷开发和传统开发的对比. 一.传统软件开发 比较常用的几种传统软件开发方法:瀑布式开发.迭代式开发.螺旋开发 ...

  7. [转]软件开发规范—模块开发卷宗(GB8567——88)

    做软件开发是有那么一套国准可参照的,当然就是那些文档了,这里列出一下所有软件开发的规范文档: 操作手册 用户手册 软件质量保证计划 软件需求说明书 概要设计说明书 开发进度月报 测试计划文档 测试分析 ...

  8. Atitit。 沉思录 与it软件开发管理中的总结 读后感

    Atitit. 沉思录 与it软件开发管理中的总结 读后感 1. <沉思录>,古罗马唯一一位哲学家皇帝马可·奥勒留所著 2 2. 沉思录与it软件开发管理中的总结 2 2.1. 要有自己的 ...

  9. 选择如何的系统更能适合App软件开发人员?

    手机这个词早已经同吃喝玩乐一样.成为了人们生活中的必备元素. 尤其是iPhone一炮走红之后,不但手机世界发生了巨大变化,整个科技产业似乎都格局性的改变.直至今日,手机市场的竞争更是日趋白炽化,这就给 ...

  10. nw.js桌面软件开发系列 第0.1节 HTML5和桌面软件开发的碰撞

    第0.1节 HTML5和桌面软件开发的碰撞 当我们谈论桌面软件开发技术的时候,你会想到什么?如果不对技术本身进行更为深入的探讨,在我的世界里,有这么多技术概念可以被罗列出来(请原谅我本质上是一个Win ...

随机推荐

  1. Date 对象 定时器

    日期对象 Date 概述:date是表示日期时间的对象,主要的方法是获取时间和设置日期时间. date声明 使用new Date声明 有4种方式 1.不设参数 是获取当前的本地时间 var date ...

  2. Verilog教程

    1. 简介 当用 Verilog 设计完成数字模块后进行仿真时,需要在外部添加激励,激励文件叫 testbench. Verilog 的主要特性: 可采用 3 种不同的方式进行设计建模:行为级描述-- ...

  3. 英国延长 UKCA 标记截止日期

    政府于 2022 年 11 月 14 日宣布,企业将有 2 年的时间来应用新的 UKCA 产品标记.在 2024 年 12 月 31 日之前,企业可以选择使用 UKCA 或 CE 标志,之后企业只能使 ...

  4. dpkt 简单应用

    import dpktfrom dpkt.utils import mac_to_str,inet_to_strcap=f'D:/test_pacp/6.pcap'with open(cap,'rb' ...

  5. 20181224蒋嘉豪-exp5

    网络对抗技术Exp5 信息搜集与漏洞扫描20181224jjh 目录 网络对抗技术Exp5 信息搜集与漏洞扫描20181224jjh 信息搜集技术与隐私保护--知识点总结 间接收集 直接收集 社会工程 ...

  6. python excel使用

    python excel使用 https://blog.csdn.net/m0_59235508/article/details/122808875 pandas不覆盖写入 https://blog. ...

  7. C语言中链表与队列

    https://www.cnblogs.com/lanhaicode/p/10432004.html

  8. jmeter性能测试小小实践

    一.测试步骤 测试计划 / 线程组 / http请求 / 监听器 / 运行脚本 / 查看报告 二.线程组 线程组:虚拟用户数 ramp up period:设置虚拟用户数需要多长的时间全部启动,如果线 ...

  9. 【Unity】Lua热重载

    写在前面 本文讨论的"Lua热重载"是基于他人现成工具和相关博文上展开的,所以这里并不会重复实现一遍工具,主要记录我的理解过程. Lua热重载 探索 偶然在知乎上翻到一篇文章&qu ...

  10. js的时间比较

    time1的传参数类型是"2022-11-10 23:23:20" 点击查看代码 function times(time1) { let now = new Date() //当前 ...