软件开发定律知多少？布鲁克、摩尔、维斯等大神名言等你来探究

菏泽炫佑科技

软件开发定律知多少？布鲁克、摩尔、维斯等大神名言等你来探究

作者：Tim

译者 | 薛明灯

这些著名的软件开发定律您知道哪些？

软件开发和其他领域一样，有一些非常有趣的定律。程序员、技术经理和架构师经常在会议和谈话中提到它们。作为新手，我们经常只是点头同意，因为我们不想让对方知道我们其实不知道 Brook、Moore 或 Weiss 是谁。

这些定律包括一些规则或者软件开发大师的名言，都很有趣，值得探究，而且每一条定律背后都有一个令人惊叹的背景故事。

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

墨菲定律

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

如果某件事可能出错，那它就一定会出错。

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

布鲁克定律

大多数开发人员都自觉或不自觉地经历过布鲁克定律，该定律指出：

在已经延期的软件项目中增加更多人手只会使项目更加延期。

如果项目进度落后，单纯增加人手很可能带来灾难性的后果。重新审视编程效率、软件开发方法、技术架构等因素，总会取得更好的结果。否则，就意味着霍夫施塔特定律也起作用了。

霍夫施塔特定律

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

当然，不要将这条定律与电视节目《生活大爆炸》中的定律相混淆软件开发定律知多少？布鲁克、摩尔、维斯等大神名言等你来探究，尽管他所说的一些内容对某些人来说可能有道理。

该法律规定：

即使考虑到霍夫施塔特定律，项目也总是需要比预期更长的时间才能完成。

这条“定律”是关于准确估计完成一项复杂任务所需时间的难度。该定律是递归的，反映了尽管你尽了*大努力并了解任务的复杂性，但估计复杂项目的难度仍然很大。

这就是为什么在进行项目估算时留有缓冲很重要的原因。

康威定律：软件的结构反映了开发该软件的组织的结构。

或者更清楚地说：

组织设计的系统的结构受到该组织的沟通结构的制约。

很多组织都是按照功能技能来划分团队的，所以会有前端开发团队、后端开发团队、数据库开发团队。简单来说，如果某个东西是别人的，别人就很难去改变它。

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

因此，围绕目标软件架构组织团队可以更容易地实现该软件架构，这是对抗康威定律的有效方法。

波斯托定律或稳健性定律是保守的输出和自由的输入。

Jon *初提出它是作为实现健壮 TCP 的原则。这一原则也体现在 HTML 中。HTML 的成功或失败可以归因于它的许多属性，但对于 HTML 是成功还是失败，不同的人有不同的看法。

帕累托原则（）或 80/20 规则 对于许多现象来说，80% 的后果来自 20% 的原因。

80%的bug来自于20%的代码，这就是帕累托原则。

有人说，一家公司 80% 的工作是由 20% 的员工完成的。问题是你不知道他们是哪 20%。

彼得原理

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

在等级制度下，每个员工都倾向于被提拔到他不具备资格的职位。

呆伯特系列漫画中有一些这样的例子。

基尔霍夫定律 ('s) 在密码学中，即使系统除了一小段信息（即密钥）之外的所有内容都是公开的，系统也应该是安全的。

这就是公钥密码学的主要原理。

莱纳斯定律

该定律以 Linux 创始人 Linus 的名字命名软件开发，其内容如下：

如果有足够多的眼睛，所有的错误都会被发现。

这条定律可以用著名的“大教堂和集市”的故事来描述，它解释了两种不同的自由软件开发模式之间的对比：

结论是，公开测试、审查和源代码实验的范围越广，各种错误就会越快被发现。

摩尔定律指出，计算机单位成本的计算能力每24个月翻一番。

*流行的版本是这样的：

集成电路上晶体管的数量大约每18个月翻一番。

或者：

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

Wirth 定律软件比硬件更容易变慢。

参考摩尔定律！

90% 的代码占用了 10% 的时间，剩余 10% 的代码又占用了剩余 90% 的时间。

有谁不同意这个观点吗？

Knuth 优化定律：过早优化是一切罪恶的根源。

先写代码，然后找到瓶颈，然后修复它们！

诺维格定律指出，任何渗透率超过 50% 的技术就永远不会再翻倍（无论需要多少个月）。

求不要再更新真香法则了，我学不会！……真的好香啊。

这是所有程序员都无法逃避的定律，你同意吗？

以上这些软件开发黄金法则，你知道多少？你还知道其他哪些软件开发黄金法则？欢迎留言告诉我们！

炫佑科技专注互联网开发小程序开发-app开发-软件开发-网站制作等