与其他领域一样，软件开发中也有一些非常有趣的法则。 程序员，技术经理和架构师经常在会议和聊天中提及他们。 作为小白，我们通常只是点头同意，因为我们不想让对方知道我们实际上不知道布鲁克，摩尔或魏斯是谁。 今天，我们将聆听您必须承认的那些软件开发法律。
这些法律包括一些伟大的软件开发神的法律或著名谚语。 它们都很有趣，值得一看，每部法律背后都有惊人的背景故事。
在本文中，我将分享我对软件开发领域最著名和最常见的软件开发法律的解释和想法。
墨菲定律
可能是最著名的定律之一，主要是因为它不仅适用于软件开发。
如果出了什么问题，那就会出错。
第一个推论：您可能尚未编写有效的代码。
第二个推论：诅咒是所有程序员都能说流利的唯一语言。
结论：计算机将执行您编写的内容（代码），而不是您想要执行的操作。
防御性编程，版本控制，世界末日情况（针对那些该死的僵尸服务器攻击），TDD，MDD等，这些都是针对此法律的防御性做法。
布鲁克定律
大多数开发人员自觉或不自觉地体验了布鲁克定律。 法律规定：
是已被推迟的软件项目。增加人力只会严重拖延该项目。
如果一个项目被延迟，仅仅增加人力可能会带来灾难性的后果。 回顾诸如编程效率，软件开发方法和技术体系结构等因素将始终带来更好的结果。 如果不是的，这意味着霍夫施塔特定律也在起作用。
霍夫施塔特定律
霍夫施塔特定律是道格拉斯·霍夫施塔特提出的，并以他的名字命名。
当然，即使他说的某些话对某些人来说有一定意义，也请不要在电视连续剧《大爆炸》中将此法与伦纳德·霍夫施塔特混淆。
of的定律指出：
即使考虑霍夫施塔特定律，项目的实际完成时间也总是比预期的长。
此“定律”是关于准确估计完成复杂任务所需的时间的难度。 该定律是递归的，反映了估算复杂项目的难度，即使您可能已尽了最大努力并且知道任务的复杂性。
这就是为什么在进行项目估算时必须有一个缓冲区。
康韦定律
软件的结构反映了开发软件的组织的结构。
或者更明确地说：
组织设计的系统结构受组织的通信结构限制。
许多组织根据职能技能划分团队，因此将有前端开发团队，后端开发团队和数据库开发团队。 简而言之，如果某人想要更改的东西属于其他人，那么他很难更改这些东西。
现在，越来越多的组织基于有限的上下文来组织团队，而微服务之类的体系结构也正在基于服务边界而不是孤立的技术体系结构分区来构建团队。
因此，通过根据目标软件体系结构组成团队，可以更轻松地实现软件体系结构，这是抵制Conway法则的有效方法。
Postel定律或稳健性定律
保守输出，自由输入。
Jon Postel最初将其用作实现健壮TCP的原理。 HTML中也反映了这一原理。 HTML的成功或失败可以归因于其许多属性，但是对于HTML是成功还是失败，不同的人有不同的看法。
帕累托原理或80/20规则
对于许多现象，80％的后果来自20％的原因。
80％的错误来自20％的代码。 这是帕累托定律。
有人说，公司80％的工作是由20％的员工完成的。 问题是您不知道哪20％的员工是。
彼得原理
这是一个相当令人沮丧的定律，尤其是如果您碰巧自己经历的定律。
在分层系统中，每个员工都倾向于被提升到他无法担任的职位。
迪尔伯特（Dilbert）系列漫画中有一些例子。
Kerchkhoff原理
在密码术中，即使系统中的所有内容都是公共的，系统也应该是安全的，除了一小部分信息（密钥）。
这是公钥加密的主要法则。
Linus定律
这是以Linux之父Linus Torvalds的名字命名的。 法律规定：
如果眼中有足够的虫子，则所有虫子都是不可见的。
著名的“大教堂和集市”可以用来描述该定律，它解释了两种不同的自由软件开发模型之间的对比：
大教堂模型-—每个软件版本都提供了源代码 代码，但版本之间的代码开发仅限于一组专有软件开发人员。
集市模型代码开发是通过Internet公开完成的。
结论？ 对源代码进行更广泛的公共测试，审查和试验将导致更快地发现各种形式的错误。
摩尔定律
单位成本计算计算能力每24个月翻一番。
The的最流行版本是：
集成电路上的晶体管数量大约每18个月就会翻一番。
或：
计算机的处理速度每两年翻一番！
Wirth定律
软件比率硬件更有可能 慢下来。
请参阅摩尔定律！
九十法则
代码的前90％占用了10％的时间，其余10％的时间 ％的代码会占用剩余90％的时间。
有人反对吗？
Knuth的优化原理
过早的优化是万恶之源。
首先编写代码，然后找到瓶颈，最后加以解决！
诺维定律
任何渗透率超过50％的技术都将 再也不会再翻一番（无论有多少个月）。
真正的香精法则
不要更新它，我无法学习！...真正的香精。
是所有程序员都无法逃避的法律，是同意吗？
您知道多少上述软件开发法律？
返回列表