15条软件开发黄金定律

2019 年 4 月 02 日

15条软件开发黄金定律

与其他领域一样,软件开发领域也有一些非常有趣的定律。程序员、技术经理和架构师们经常在会议和聊天中提到它们。作为小白,我们常常只有点头附和的份,因为我们不希望让对方知道我们实际上根本不知道布鲁克、摩尔或者维斯都是什么人。


这些定律包括了一些法则或软件开发大神的名言。它们都很有趣,值得我们一探究竟,而且每个定律背后都有令人惊叹的背景故事。


在这篇文章中,我将分享我对软件开发领域最著名和最常见的定律的解释和想法。


一、墨菲定律(Murphy’s Law)


可能是最著名的定律之一,主要是因为它不仅适用于软件开发。


如果事情可能出错,它就会出错。


  • 第一个推论:那些有效的(代码),你可能反而没有写出来。

  • 第二个推论:诅咒是唯一一门所有程序员都能流利说出来的语言。

  • 结论:电脑会按照你所写的(代码)去做,而不是按照你所想的去做。


防御性编程、版本控制、末日场景(针对那些该死的僵尸服务器攻击)、TDD、MDD,等等,这些都是针对这一定律的防御性实践。


二、布鲁克定律(Brook’s Law)


大多数开发人员都有意无意地经历过布鲁克定律,该定律指出:


为已经延期的软件项目增加人手只会让项目延期得更厉害。


如果一个项目出现了延期,只是简单地增加人手很可能会带来灾难性的后果。对编程效率、软件开发方法、技术架构等因素进行评审总是会带来更好的结果。如果没有,那说明霍夫施塔特定律也在起作用。


三、霍夫施塔特定律(Hofstadter’s Law)


霍夫施塔特定律由 Douglas Hofstadter 提出,并以他的名字命名。


当然,不要将这个定律与电视剧《大爆炸》里的 Leonard Hofstadter 混淆起来了,尽管他说的一些话对某些人来说是有一点意义的。



这个定律指出:


即使你考虑到了霍夫施塔特定律,项目的实际完成时间总是比预期的要长。


这个“定律”是关于准确预估完成复杂任务所需时间的难度。这个定律具有递归性,反映了预估复杂项目的难度,尽管你可能已经做出了最大的努力,而且也知道任务的复杂性。


这就是为什么在进行项目预估时必须要有一个缓冲区。


四、康威定律(Conway’s Law)


软件的结构反映了开发软件的组织的结构。


或者说得更清楚一点:


组织所设计的系统的结构受限于组织的通信结构。


很多组织是根据功能性技能来划分团队的,所以会有前端开发团队、后端开发团队和数据库开发团队。简单地说,如果某人想要改变的东西属于其他人,那么他就很难改变这些东西。


现在越来越多的组织根据有界上下文来组建团队,而微服务等架构也在根据服务边界而不是孤立的技术架构分区来组建团队。


因此,根据目标软件架构来组建团队可以更容易实现软件架构,而这就是对抗康威法律的一种有效方式。


五、波斯托定律(Postel’s Law)或鲁棒性法则


保守输出,自由输入。


Jon Postel 最初将它作为实现健壮的 TCP 的一个原则。这个原则也体现在 HTML 中,HTML 的成败可以归因于它的很多属性,但究竟 HTML 是成功的还是失败的,不同的人有不同的看法。


六、帕累托法则(Pareto Principle)或 80/20 法则


对于很多现象,80%的后果源于 20%的原因。


80%的 bug 来自 20%的代码,这个说的就是帕累托法则。


还有人说,公司里 80%的工作是由 20%的员工完成的,问题是你并不清楚是哪 20%员工。


七、彼得法则(The Peter Principle)


这是一个相当令人沮丧的定律,特别是如果你碰巧亲身经历过。


在一个等级制度中,每个员工都倾向于晋升到他无法胜任的职位。


呆伯特(Dilbert)系列漫画中有一些这方面的例子。



八、基尔霍夫法则(Kerchkhoff’s Principle)


在密码学中,系统应该是安全的,即使系统的所有东西都是公开的——除了一小部分信息——秘钥。


这是公钥密码学的主要法则。


九、莱纳斯定律(Linus’s Law)


这是以 Linux 之父 Linus Torvalds 的名字命名的,该定律指出:


如果有足够多的眼睛,所有的 bug 都将无所遁形。


可以使用著名的《大教堂与集市》来描述这个定律,它解释了两种不同的自由软件开发模型之间的对比:


  • 大教堂模型——每个软件发行版都提供源代码,但发行版之间的代码开发仅限于一组专有的软件开发人员。

  • 集市模型——代码开发通过互联网公开进行。


对源代码进行更广泛的公开测试、评审和实验,就会更快地发现各种形式的 bug。


十、摩尔定律(Moore’s Law)


单位成本的计算机算力每 24 个月翻一番。


最流行的版本是说:


集成电路上的晶体管数量大约每 18 个月会增加一倍。


或者:


计算机的处理速度每两年翻一番!



十一、沃斯定律(Wirth’s Law)


软件比硬件更容易变慢。


参考一下摩尔定律吧!


十二、九九法则(Ninety-Ninety Rule)


前 90%的代码占用了 10%的时间,其余的 10%代码占用了剩下的 90%时间。


有人不同意这个的吗?


十三、克努特优化法则(Knuth’s Optimization Principle)


过早优化是万恶之源。



先写代码,然后找出瓶颈,最后才修复!


十四、诺维格定律(Norvig’s Law)


任何超过 50%渗透率的技术都不会再次翻倍(无论在多少个月内)。


十五、真香定律


别更新了,我学不动了!……真香。


所有程序员都逃不过的定律,同意吗?


2019 年 4 月 02 日 15:2015750
用户头像

发布了 731 篇内容, 共 359.6 次阅读, 收获喜欢 1824 次。

关注

评论 1 条评论

发布
用户头像
什么乱七八糟的定律,真香定律一统天下
2019 年 04 月 09 日 17:20
回复
没有更多评论了
发现更多内容

深入浅出SpringMVC系列~

程序员的时光

spring springmvc

高内聚与低耦合

落英亭郎

面向对象 高内聚 低耦合

分布式数据库

Leiy

两边夹的应用三

孙苏勇

算法 两边夹

你没必要活的那么累

小天同学

深度思考 个人成长 生活 成长 感悟

k8s上运行我们的springboot服务之——简单的架构思考

柠檬

k8s springboot

健康饮食和定期运动带给我们的一点启示

七镜花园-董一凡

生活质量

乙己说:LRU实现思路整理

再见小飞侠

golang 缓存 LeetCode

语雀性感,印象迟暮。

彭宏豪95

学习 工具 在线办公

我的事务为什么会失效

JFound

spring

JVM源码分析之JVM启动流程

猿灯塔

小岑的架构学习笔记-架构设计的历史背景

程序员小岑

程序员的晚餐 | 5 月 21 日 四季豆炒腊肠

清远

美食

云上数据库类产品的模式与发展趋势

韩超

数据库 redis 腾讯云 阿里云

小岑的架构学习笔记-架构是什么?

程序员小岑

传统岗位新挑战:信息安全之路

nexpose

安全架构师 安全 安全管理

科学理论的反思

美多丽可

学习

怎么用"设计思维"思考产品?

Yanel 说敏捷产品

产品 设计 产品设计 产品开发

Golang testing: “no test files”

北纬32°

golang

实战!我用 Wireshark 让你 “看得见“ TCP

小林coding

Linux TCP 计算机网络

码农理财(二)

北漂码农有话说

Review week1: Amazon的领导力法则

猫吃小怪兽

学习 高效工作 程序员 个人成长

k8s上运行我们的springboot服务之——热点数据

柠檬

redis

KubeSphere权威指南(一)--------使用KubeSphere创建Percona Server,并对外暴露端口

赵欣

k8s percona server

Python 如何随机打乱列表(List)排序

Young先生

Python List random 随机

Spring注入的对象到底是什么类型

JFound

spring

乙己说:NUMA是个啥?

再见小飞侠

jdk G1 ZGC 内存

Android | Tangram动态页面之路(六)数据分离

哈利迪

android

[从零学习Spring Cloud]Nacos配置中心

玏佾

Spring Cloud nacos

数据产品经理实战-开篇

第519区

产品经理

要弄清楚if/switch的本质区别,以及优化方式

张驰

Java

15条软件开发黄金定律-InfoQ