如果我们的环境是原始的，我们就有动力保持这种状态。 环境越混乱，我们增加混乱的门槛就越低。 毕竟一团糟……谁在乎我们是否再加一点呢？
我们可以从这条规则中获得的主要好处是我们应该意识到我们周围的混乱。 如果事情发展到人们已经习惯了并且不再关心它的时候，最好给混乱带来一些秩序。
如何将其应用到软件开发中？
在软件开发中，我们可以将其应用于代码质量：我们在代码库中引入的每一个代码异味都会降低我们添加更多代码异味的门槛。 我们应该[[开始清理]]并保持代码库干净以避免这种情况发生。 许多代码库如此难以理解和维护的原因是损坏的窗口已经悄悄出现并且修复得不够快。
我们也可以将这个原则应用于测试覆盖率：一旦一定数量的代码进入测试未覆盖的代码库，就会添加更多未覆盖的代码。 这是维持 100% 代码覆盖率（应该覆盖的代码）的一个论点，因此我们可以在窗口破裂之前看到裂缝。
3.奥卡姆剃刀
内容
哲学剃刀是一种通过消除（或“削减”）不太可能的假设来帮助解释某些事物的原理。 奥卡姆剃刀说软件开发，如果有多个假设，我们应该选择假设最少的一个（这可能是最容易解释的）。
如何将其应用到软件开发中？
我们可以将奥卡姆剃刀应用于事件分析。 您可能遇到过这样的情况：用户报告您的应用程序存在问题，但您不知道导致这些问题的原因。 因此，您正在搜索日志和指标，试图找到根本原因。
下次用户报告错误时，请维护事件调查文档。 写下你对导致问题的原因的假设。 然后，对于每个假设，列出事实和猜想。 如果假设被证明为真，则将其标记为事实。 如果事实证明某个假设是错误的，请将其从文档中删除或将其标记为错误。 在任何时候，您现在都可以将时间集中在最有可能的假设上，而不是浪费时间来转移注意力。
4. 邓宁-克鲁格效应
内容
邓宁-克鲁格效应表明，没有经验的人往往会高估自己的能力，而有经验的人往往会低估自己的能力。
如果你不擅长某件事，你就会认为自己很擅长。 如果你擅长某件事，但你认为自己不擅长，这可能会导致冒名顶替综合症，这会让你怀疑自己的能力，以至于你在其他拥有类似技能的人中感到不舒服（担心别人会认为你“不擅长”）。不正确）。
如何将其应用到软件开发中？
认识到这种认知偏差已经是朝着正确方向迈出的重要一步。 它将帮助您更好地评估自己的技能，以便您可以寻求帮助，或克服自我怀疑并自行采取行动。
一种有助于抵消邓宁-克鲁格效应和冒名顶替综合症的做法是结对或小组编程。 您不再独自工作，陷入自我怀疑或优越感，而是与他人密切合作，交流想法，边学边教。
但是，这仅适用于安全环境。 在崇尚个人主义的环境中，结对或小组编程可能会导致更多的自我怀疑或更多的优越感。
5.彼得原理
内容
彼得原理指出，只要你在工作中表现出色，你就会得到晋升，直到晋升到你不适合的工作为止。 由于你不再成功，你将不再获得晋升，这意味着你将生活在一份不会给你带来满足或成功的工作中，通常是你的余生。 前景黯淡！
如何将其应用到软件开发中？
在软件开发中，当您从开发人员职业转变为管理职业时，彼得原则通常适用。 然而，成为一名优秀的开发人员并不一定意味着你就是一名优秀的经理。 或者，你可能是一名优秀的经理，但你并没有因为经理的工作而不是开发人员的工作而感到满意，这意味着你没有全力以赴（这就是发生在我身上的事情）。 无论如何，你都很痛苦，看不到你前面的职业道路有任何未来的发展。 在这种情况下，请退后一步，思考一下您希望自己的职业生涯是什么样子。 然后，切换角色（或公司，如有必要）以获得您想要的角色。
6.帕金森定律
内容
帕金森定律指出，工作总是填满分配给它的时间。 如果您的项目的截止日期在两周内，则该项目将不会在此之前完成。 是的，这可能需要更长的时间，但绝不会少于我们分配的时间，因为我们用不必要的工作或拖延来填补这段时间。
如何将其应用到软件开发中？
帕金森定律的主要驱动力是：
为了对抗拖延症，我们可以将最后期限设定为几天而不是几周或几个月。 说出接下来的2-3天内需要做什么才能实现目标？ 一个（健康的！）截止日期可以给我们足够的动力，不至于陷入拖延的低谷。 为了防止范围蔓延，我们应该非常清楚我们的项目想要实现什么目标。 衡量成功的标准是什么？ 这个新功能会增加这些指标吗？ 好吧，如果每个人都明白这项工作需要更长的时间，我们应该添加它。 如果新功能与使命宣言不符，就放弃它。
7.霍夫施塔特定律
内容
霍夫施塔特定律指出“即使考虑到霍夫施塔特定律，它所花费的时间总是比您预期的要长”。 即使您了解这条法则，并增加项目的时间分配，它仍然会比您预期的时间更长。 这与帕金森定律密切相关，该定律指出工作总是会填满分配给它的时间。 只是霍夫施塔特定律说它占用的时间比分配的时间多。 这一定律得到了心理学的支持。 我们很容易陷入所谓的“计划谬误”，即我们在估计工作量时通常不会考虑所有可用的信息，即使我们认为我们已经考虑了。 我们的估计几乎总是主观的，很少是正确的。
如何将其应用到软件开发中？
在软件开发（以及任何其他基于项目的工作，实际上）中，我们人类的乐观主义盛行。 估计几乎总是过于乐观。 为了减少霍夫施塔特定律的影响，我们可以尝试尽可能客观地估计。 写下有关该项目的假设和事实列表。 将每个库存元素标记为假设或事实，以使数据质量可见并管理预期。 不要依赖直觉，因为每个人的感觉都不一样。 写下估计值并让你的大脑思考它们。 将它们与其他人的估计进行比较，并讨论差异。 即便如此，这仍然只是一个估计，可能并不能反映现实。 如果估算不是基于统计数据或其他历史数据，那么估算的价值就很小，因此与要求您估算的人一起管理期望总是好的 - 这总是会出错。 如果你尽可能客观，就会减少错误。
8.康威定律
内容
康威定律指出，组织创建的任何系统都将类似于该组织的团队和通信结构。 如果您有 10 个团队在开发一个系统，那么最终可能会有 10 个相互通信的子系统。
如何将其应用到软件开发中？
我们可以应用所谓的逆康威策略：创建最能支持我们想要构建的系统架构的组织结构。 没有固定的团队结构，但有足够的灵活性来创建和解散团队，这最适合系统的当前状态。
9.墨菲定律
内容
墨菲定律说，任何可能出错的事情就一定会出错。 事故发生后经常被引用。
如何将其应用到软件开发中？
软件开发是一个容易出错的职业。 错误的主要来源是错误。 任何软件都存在挑战用户耐心的错误或事件。 我们可以通过在日常软件开发实践中养成减少错误影响的习惯来抵消墨菲定律。 我们无法完全避免错误，但我们可以而且应该减少错误对用户的影响。 反对墨菲定律的最有用的做法是特征标记。 如果我们使用像 LaunchDarkly 这样的功能标记平台，我们可以将更改部署到功能标记后面的生产中。 然后，我们可以使用有针对性的版本来激活内部测试标志，然后发布给少数友好的测试版用户，最后将其推广给所有用户。 通过这种方式，我们可以从日益关键的用户群体中获得有关更改的反馈。 如果更改出错（在某些时候会出错），影响很小，因为只有一小部分用户组受到影响。 此外，该标志可以快速关闭。
10.布鲁克定律
内容
在经典著作《人月神话》中，弗雷德·布鲁克（Fred Brook）有句名言：向已晚的项目添加人力会使项目变得更晚。 尽管本书讨论的是软件项目，但它适用于大多数类型的项目，甚至在软件开发之外。 添加人员不会提高项目速度的原因是，项目的通信开销随着每个人添加到项目中而呈指数级增长。 2 个人有 1 条通信路径，5 个人已经有 120 条可能的通信路径。 新人需要时间来适应并找出他们需要的沟通路径，这就是为什么当新人添加到项目中时，迟到的项目会来得更晚。
如何将其应用到软件开发中？
很简单。 更改截止日期，而不是向已经迟到的项目添加人员。 对向软件项目添加新人员的期望要切合实际。 向项目添加人员可能会在某些时候提高速度，但并非总是如此，而且肯定不会立即提高速度。 人员和团队需要时间来适应日常工作，并且在某些时候，工作无法足够并行化，因此添加更多人员是没有意义的。 仔细考虑新人应该完成哪些任务以及将该人添加到项目中时您的期望。
海报定律
内容
波斯特尔法则也被称为保守主义原则，它规定你应该“在你所做的事情上保持保守，在接受他人的事情上保持开放”。 换句话说，您可以接受多种不同形式的数据软件开发，以使您的软件尽可能灵活，但您应该非常小心地处理这些数据，以免无效或恶意数据损害您的软件。
如何将其应用到软件开发中？
该定律源于软件开发，因此它的应用非常直接。 您的软件与其他软件或开发人员之间的接口应允许不同形式的输入以保证稳健性：
然而，如果我们愿意接受不同格式的数据，我们在处理这些数据时必须保守。 我们必须审查无效值，并确保我们不会因为允许太多不同的格式而损害系统的安全性。 SQL 注入可能是由于对用户输入过于宽松而导致的攻击。
11.基尔霍夫原理
内容
Kerchkhoff 的原则指出，即使加密方法是公开的，加密系统也应该是安全的。 只有用于解密的密钥才需要保密。
如何将其应用到软件开发中？
这很容易，真的。 永远不要相信要求其加密方法保密的加密系统。 这称为“通过默默无闻实现安全”。 像这样的系统本质上是不安全的。 这种加密方法一旦暴露于公众，就很容易受到攻击。
12.莱纳斯定律
内容
Eric Raymond 在他关于 Linux 内核开发的书《The Cathedral and the Bazaar》中写道：“有足够多的眼睛可以让所有问题浮出水面”。 他将此称为“莱纳斯定律”，以纪念莱纳斯·托瓦尔兹。 这意味着如果很多人查看代码，则比很少人查看代码更容易暴露代码中的错误。
如何将其应用到软件开发中？
如果您想消除错误，请让其他人查看您的代码。 起源于开源社区的一种常见做法是让开发人员发出包含代码更改的拉取请求，然后让其他开发人员在将拉取请求合并到主分支之前检查该拉取请求。 这种做法也延续到了闭源开发中，但根据 Linus 定律，拉取请求在闭源环境（只有少数人查看）中的用处不如在开源环境（其中可能有许多贡献者）有用。看着它）。 其他让更多人关注代码的方法是结对编程和小组编程。 至少在闭源环境中，这些比拉取请求审查更能有效地避免错误，因为每个人都参与了代码的初始阶段，这为每个人提供了更好的背景来理解代码和潜在的错误。
13.沃斯定律
内容
沃斯定律指出，软件变慢的速度比硬件变快的速度快。
如何将其应用到软件开发中？
不要依赖强大的硬件来运行性能不佳的代码。 相反，编写经过优化以实现良好性能的代码。 这必须与（软件开发法则：Knuth 的优化原则）这句格言相平衡，“过早的优化是万恶之源”。 不要花费更多的精力让代码运行得比为用户构建新功能更快。 通常，这是一种平衡行为。
十四、Knuth优化原理
内容
Donald Knuth 在他的一本著作中写下了“过早的优化是万恶之源”这句话，这句话经常被断章取义，并用作根本不关心优化代码的借口。
如何将其应用到软件开发中？
根据高德纳定律，我们不应该过早地浪费精力优化代码。 然而，根据沃斯定律，我们也不应该依赖足够快的硬件来执行优化不佳的代码。 最后，我从这些原则中学到了以下内容： 优化可以轻松完成的代码，无需太多努力：例如，编写几行额外的代码以避免经历可能包含大量项目的循环。 优化始终执行的关键业务代码。 除此之外，除非您发现了性能瓶颈，否则不要花费太多精力来优化代码。
保持怀疑
法律和原则是好的。 这使我们能够从没有它们就不可能的角度来评估某些情况。 然而，盲目地将法律和原则应用于所有情况是行不通的。 每种情况都会出现微妙的变化，这可能意味着某个原则不能或不应该适用。 对你遇到的原则和法律持怀疑态度。 世界不是黑白的。