软件开发定律:海勒姆定律(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 的依赖关系和稳定性。这种做法会使代码的依赖关系变得混乱和不可控,增加了代码的复杂性和难以维护性。
综上所述,避免这些常见的反模式,能够更好地落实海勒姆定律,提高代码的可维护性和稳定性,同时也能够更好地适应软件开发过程中的变化和创新。
最后
海勒姆定律是一个非常重要的原则。其告诉我们,在处理复杂系统时,我们不能只关注系统的主要功能,还需要考虑系统中的各种依赖关系和副作用。
如果我们只是假设一切都是正确的,并没有考虑到系统的各种依赖关系和副作用,那么就会遇到各种意外和问题,这可能会导致系统崩溃或出现其他严重问题。
在编写代码时,我们应该注意避免海勒姆定律的陷阱,并考虑使用一些最佳实践来确保代码的稳定性和可靠性。
总之,海勒姆定律的重要性不能被忽视。对于开发人员来说,了解这个原则,并在实践中应用它,将有助于提高代码的质量和稳定性,从而为用户提供更好的体验。
阅读,思考,练习,分享,日日不断之功。
嗯,写完了。
新的一天,加油哦 (ง •̀_•́)ง
软件开发定律:海勒姆定律(Hyrum's Law)的更多相关文章
- 敏捷软件开发VS传统软件工程
敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同 ...
- Atitit.软件开发的三层结构isv金字塔模型
Atitit.软件开发的三层结构isv金字塔模型 第一层,Implements 层,着重与功能的实现.. 第二次,spec层,理论层,设计规范,接口,等.流程.方法论 顶层,val层,价值观层,原则, ...
- Atitit.软件开发的几大规则,法则,与原则Principle v3
Atitit.软件开发的几大规则,法则,与原则Principle v31.1. 修改历史22. 设计模式六大原则22.1. 设计模式六大原则(1):单一职责原则22.2. 设计模式六大原则(2):里 ...
- 软件开发的一些"心法"
从事软件开发也有好几年了,和一开始那个懵懵懂懂的小菜鸟相比,自己也感觉到了一些变化. 也许是熟能生巧, 趟过很多坑,但核心的绝不是这些细节的东西. 打个比方,如果说对某种语言的特性和技巧的掌握属于身法 ...
- 敏捷软件开发 VS. 传统软件工程
敏捷软件开发 VS. 传统软件工程 软件工程这一术语1968年被提出,之后美国软件工程专家巴利·玻姆对十多年间研究软件工程的专家学者们提出的一些准则与信条,于1983年对提出软件工程的七条基本定理,将 ...
- 敏捷软件开发vs传统软件开发
摘要 本文介绍了传统软件开发(着重介绍了传统软件开发中常用的瀑布模型)和敏捷软件开发,以及敏捷开发和传统开发的对比. 一.传统软件开发 比较常用的几种传统软件开发方法:瀑布式开发.迭代式开发.螺旋开发 ...
- [转]软件开发规范—模块开发卷宗(GB8567——88)
做软件开发是有那么一套国准可参照的,当然就是那些文档了,这里列出一下所有软件开发的规范文档: 操作手册 用户手册 软件质量保证计划 软件需求说明书 概要设计说明书 开发进度月报 测试计划文档 测试分析 ...
- Atitit。 沉思录 与it软件开发管理中的总结 读后感
Atitit. 沉思录 与it软件开发管理中的总结 读后感 1. <沉思录>,古罗马唯一一位哲学家皇帝马可·奥勒留所著 2 2. 沉思录与it软件开发管理中的总结 2 2.1. 要有自己的 ...
- 选择如何的系统更能适合App软件开发人员?
手机这个词早已经同吃喝玩乐一样.成为了人们生活中的必备元素. 尤其是iPhone一炮走红之后,不但手机世界发生了巨大变化,整个科技产业似乎都格局性的改变.直至今日,手机市场的竞争更是日趋白炽化,这就给 ...
- nw.js桌面软件开发系列 第0.1节 HTML5和桌面软件开发的碰撞
第0.1节 HTML5和桌面软件开发的碰撞 当我们谈论桌面软件开发技术的时候,你会想到什么?如果不对技术本身进行更为深入的探讨,在我的世界里,有这么多技术概念可以被罗列出来(请原谅我本质上是一个Win ...
随机推荐
- MySQL事务MVCC、undolog和redolog
MySql的MVCC多版本控制 undolog:回滚日志(保证一致性)只有在ReadCommited和RepeatableRead隔离级别有用 redolog:重写日志(保证持久性) 示例讲解 Rea ...
- LeetCode 删除数组中重复项 26 80
26(80) 给你一个 升序排列 的数组 nums ,请你 原地 删除重复出现的元素,使每个元素只出现一次(使得出现次数超过两次的元素只出现两次 ) ,返回删除后数组的新长度.元素的 相对顺序 应该保 ...
- android studio真垃圾
开发人员写代码就行了,想用你写代码,安装配置费死个劲! 我不是针对你,除了visual studio ,所有的IDE都是垃圾.
- NOI 顺序查找——查找特定的值
描述 在一个序列(下标从1开始)中查找一个给定的值,输出第一次出现的位置. 输入 第一行包含一个正整数n,表示序列中元素个数.1 <= n <= 10000.第二行包含n个整数,依次给出序 ...
- PHP操作MySQL批量Update的写法,各框架通用防注入版
使用别人的扩展遇到了问题,发现没有做SQL注入的处理.我又写了个轮子,根据自己需求扩展了下,有需要的小伙伴可以直接取用. 这里就直接粘贴源码了,会用PHPD ,基本都会如何把它运用到各个框架里的. 本 ...
- django_设计模式和模板层
一.django的设计模式 1.传统MVC设计模式 (1)MVC(Model-View-Controller,模型-视图-控制器)模式. M--模型层,主要用于对数据库的封装: V--视图层,用于向用 ...
- 艾思最新案例分享:塔蓝物流app-物流仓储管理系统app. app开发
塔蓝物流app是一款物流仓储管理app:主要业务范围空运,海运,进出口货物及过境货物的运输代理,包括揽物订舱,仓储(危险品除外),包装,搬运装卸,中转,流通加工,集装箱拼装拆箱(危险品除外),结算运杂 ...
- R 曲线拐点
x = seq(1,15) y = c(4,5,6,5,5,6,7,8,7,7,6,6,7,8,9) plot(x,y,type="l",ylim=c(3,10)) lo < ...
- 网络存储服务ip-san搭建
网络存储服务ip-san搭建 ip-san简称SAN(Storage Area Network),中文意思存储局域网络,ip- ...
- CH573 CH582 CH579蓝牙主机(Central)例程讲解一(主机工作流程)
蓝牙主机,顾名思义,就是一个蓝牙主设备,与从机建立连接进行通信,可以接收从机通知,也可以给从机发送信息,可将Central例程和Peripheral例程结合使用. 蓝牙主机例程的工作流程大致如下: 一 ...