著名软件开发定律（2017）

和其他任何领域一样，软件开发领域也有一些有趣而著名的规则、原则和法则。程序员、开发人员、经理和架构师经常在对话、会议和聊天中使用这些工具。我们往往会点头同意，不愿意让谈话伙伴知道我们'；我从没听说过布鲁克、摩尔或沃思这些角色。

这些法律由规则、原则或发展世界中伟大而鼓舞人心的人物的名言组成。同时，它们有趣、有趣、值得了解，而且都有很棒的背景故事，读起来非常棒。

在这篇文章中，我将分享我对软件开发中最著名和最常用的定律的收集、解释和想法。

这是一个很大的帖子，所以我'；如果你想跳过一些，我已经包括了一个索引：

可能是所有法律中最著名的一条，主要是因为它不仅适用于软件开发。

第一个推导：如果有效，你可能没有'；我不会写的。第二点：诅咒是所有程序员都能流利地说的唯一语言。结论：电脑会做你写的，而不是你想要的。

防御性编程、版本控制、末日场景#39；s（对于那些该死的僵尸服务器攻击）、TDD、MDD等都是抵御该法律的良好实践。

如果一个项目进展缓慢，仅仅增加人力很可能会带来灾难性的后果。查看和审查编程效率、软件方法、技术架构等的水平几乎总是会有更好的结果。或者不是，这可能意味着霍夫斯塔特'；中国的法律也在发挥作用。

当然，这条定律不能与大爆炸理论中的伦纳德·霍夫斯塔特混淆。尽管他的话对你们有些人来说是有意义的。

即使考虑到霍夫斯塔特'；这是法律。

34岁；法律和#34；是关于准确估计完成相当复杂的任务所需时间的难度的声明。该定律的递归性质反映了尽管尽了最大努力（包括知道任务是复杂的）估计复杂任务的普遍困难。

那'；这就是为什么在进行任何评估之前，你必须有一个缓冲区。如果你想更多地了解如何提供更好的估计，请阅读我关于这个主题的帖子：估计魔法。

设计系统的组织必须制作这些组织通信结构的副本。

在许多组织中，团队根据其职能技能进行划分。所以你'；我们将有前端开发人员、后端开发人员和数据库开发人员组成的团队。简单地说，它'；如果某人想要改变的东西是别人的，那么他/她很难改变。

围绕一个有限的环境部署团队要好得多，而且越来越多地得到实现。微服务等体系结构围绕服务边界而不是孤立的技术体系结构分区来组织团队。

因此，组织团队，使其看起来像你的目标架构，这样会更容易实现。那'；这就是你如何抵御康威的方法'；这是法律。

Jon Postel最初将此表述为使TCP实现健壮的原则。HTML也体现了这一原则，许多人认为HTML是成功和失败的原因，这取决于你问谁。

这就是令人痛苦的事实背后的原理，即代码中80%的bug来自20%的代码。否则，公司80%的工作由20%的员工完成。问题是你没有'；I don’我并不总是清楚20%是哪个。

如果你碰巧有第一手经验，这是一条相当令人沮丧、有时令人沮丧的法律。

只要阅读Dilbert（或观看办公室）就可以得到一些实际的例子。至于迪尔伯特，这个远远不是我最喜欢的！

在密码学中，一个系统应该是安全的，即使该系统的所有内容，除了一小段信息——密钥——都是公共知识。

这条法律是用著名的《大教堂与集市》一文描述的，解释了两种不同的自由软件开发模式之间的对比：

Cathedral模式，在该模式中，每个软件版本都可以使用源代码，但在不同版本之间开发的代码仅限于软件开发人员的专属群体。

Bazaar模式，其中代码是在互联网上为公众开发的。

结论是什么？源代码用于公共测试、审查和实验的范围越广，所有形式的bug被发现的速度就越快。

前90%的代码占用了10%的时间。剩下的10%需要另外90%的时间

任何超过50%渗透率的技术都不会再翻一番（在任何数月内）。

我喜欢这些'；法律和#39；因为他们每个人都有自己的故事，各自的背景。作为一名顾问或建筑师，你必须熟悉他们。所以对我来说，也许对你们来说，我知道有一个软件开发中最常用和最著名的定律的列表！

我错过你最喜欢的法律了吗？你是否（或不）同意每一条法律，或对其中一条有任何（有趣的）经历？你最喜欢什么？使用评论部分让我知道！