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