沈阳互助盘软件软件开发的规律和原则

人们在围绕软件开发的讨论中，几乎不可避免会随口引用一两条原则。

你可能听过人们说：“这行不通，因为‘X法则’！”。或者“你不知道‘Y原则’吗？”你是哪种类型的软件开发人员？

有许多规律和原则可以引用，其中大部分都基于真理。然而，盲目地使用像上面这样的陈述来应用它们肯定会导致自负和失败。

本文沈阳互助盘软件列举了一些可以应用于软件开发的流行的规律和原则。对于每条定律，我们将快速讨论其主要内容，然后探讨如何将其应用于软件开发（也许何时不应该）。

帕累托原则（80/20 法则）

内容

帕累托原则指出，通常 80% 的结果来自 20% 的原因。数字 80 和 20 无论如何都不是准确的，但该原则的总体思路是结果通常分布不均。

我们可以看到生活的许多领域遵守着这条规则，例如：

世界上富有的 20% 的人创造了世界 80% 的收入。

80%的犯罪是由20%的罪犯所为（自 2020 年以来）。

我们知道 80% 的病毒传播来自 20% 的受感染人群。

如何应用在软件开发中？

我们可以从帕累托原则中获得的主要好处是专注。它可以帮助我们专注于重要的事情（20%），而不是在不重要的事情（其他 80%）上浪费时间和精力。不重要的事情对我们来说往往很重要，因为这样的事情总是有太多（而且看起来很紧急） 。但是较好的结果往往是通过关注重要的少数来达成的。

在软件开发中，我们可以使用它来专注于构建正确的功能，例如：

专注于实现80%产品价值的那20%的产品功能。

专注于导致 80% 用户使用异常的那 20% 的错误。

专注于实现80% 的产品功能需要的那20%总构建时间

只要问“现在重要的事情是什么？”就可以帮助建立下一个重要的事情，而不是下一个紧急的事情。

顺便说一下，敏捷和 DevOps 等现代的开发方法有助于获得这种关注！具有定期用户反馈的快速迭代允许对重要事项进行数据驱动的决策。诸如基于主干的带有功能标记的开发之类的实践可以帮助软件团队实现这一目标。

破窗定理

内容

破碎的窗户会招致破坏，因此很快所有窗户都被打破。

一般来说：混乱会招致更多的混乱。

如果我们的环境是原始的，我们就会有动力保持这种状态。环境中的混乱越多，我们添加混乱的门槛就越低。毕竟已经混乱了……谁在乎我们是否再添加一点呢？

我们可以从这条规则中获得的主要好处是我们应该意识到我们周围的混乱。如果它达到人们习惯于不再关心它的程度，那么较好为混乱带来一些秩序。

如何应用在软件开发中？

在软件开发中，我们可以将其应用于代码质量：我们引入代码库的每一种代码异味都会降低我们添加更多代码异味的门槛。我们应该 [[Start Clean]] 并保持代码库干净以避免这种情况发生。许多代码库如此难以理解和维护的原因是，破窗已经悄然出现并且没有足够快地修。

我们也可以将这个原则应用到测试覆盖率上：一旦有相应数量的代码进入了未被测试覆盖的代码库，就会添加更多未被覆盖的代码。这是保持 100% 代码覆盖率（应该覆盖的代码的）的论据，因此我们可以在窗口破裂之前看到裂缝。

奥卡姆剃刀

内容

哲学剃刀是一种通过消除（或“削除”）不太可能的假设来帮助解释某些事情的原则。奥卡姆剃刀表示，如果有多个假设，我们应该选择假设条件较少的假设（这很可能是解释较简单的假设）。

如何应用在软件开发中？

我们可以在事件分析中应用奥卡姆剃刀。您可能遇到过这样的情况：用户报告了您的应用程序存在问题，但您不知道导致问题的原因。因此，您正在搜索日志和指标，试图找到根本原因。

下次用户报告错误时，请维护事件调查文档。写下您对导致问题的原因的假设。然后，对于每个假设，列出事实和猜想。如果假设被证明是正确的，则将其标记为事实。如果一个假设被证明是错误的，请将其从文档中删除或将其标记为错误。在任何时候，您现在都可以将时间集中在可能的假设上，而不是浪费时间转移注意力。

彼得原理

内容

彼得原理指出，只要你在工作中表现出色，你就会得到晋升，直到你晋升得到一份你不称职的工作。由于您不再成功，您将不再获得晋升，这意味着您将生活在一份不会给您带来满足感或成功的工作中，通常是在您的余生中。前景黯淡！

如何应用在软件开发中？

在软件开发中，当您将角色从开发人员职业转换为管理职业时，彼得原则通常适用。然而，成为一名开发人员并不意味着你是一名较好的经理。或者，您可能是一名较好的经理，但不要在开发人员的工作上获得经理工作的满足感，这意味着您没有全力以赴（这就是我的情况）。在任何情况下，你都很悲惨，在你面前的职业道路上看不到任何未来的发展。在这种情况下，退后一步想想，你希望你的职业是什么样子的。然后，转换角色（或公司，如果需要）以获得您想要的角色。

帕金森定律

内容

帕金森定律指出，工作总是会填满分配给它的时间。如果您的项目在两周内有截止日期，则该项目将不会在此之前完成。可能需要更长的时间，是的，但绝不会少于我们为它分配的时间，因为我们正在用不必要的工作或拖延来填补时间。

如何应用在软件开发中？

帕金森定律的主要驱动因素是：

拖延症（“截止日期太远了，所以我现在不需要匆忙……”）

范围蔓延（“当然，我们可以添加这个小功能，它不会花费我们太多时间......”）

为了对抗拖延，我们可以在几天而不是几周或几个月内设定最后期限。比如说在接下来的 2-3 天内需要做什么才能朝着目标前进？一个（健康的！）截止日期可以给我们足够的动力，不要陷入拖延症的低谷。为了防止范围蔓延，我们应该非常清楚地了解我们试图通过项目实现的目标。成功的衡量标准是什么？这个新功能是否会增加这些指标？那么如果每个人都明白这项工作需要更长的时间，我们应该添加它。如果新功能与使命宣言不匹配，请抛弃它。

霍夫施塔特定律

内容

霍夫施塔特定律指出“它总是比您预期的要长，即使您考虑到霍夫施塔特定律”。即使您了解了这条定律，并增加了项目的时间分配，它仍然会比您预期的要长。这与帕金森定律密切相关，即工作总是会填满分配给它的时间。只是霍夫施塔特定律说它填充的时间超过了分配的时间。这条定律得到了心理学的支持。我们容易犯所谓的“计划谬误”，即在估算工作量时，我们通常不会考虑所有可用信息，即使我们认为我们已经考虑了。我们的估计几乎总是主观的，很少是正确的。

如何应用在软件开发中？

在软件开发中（以及任何其他基于项目的工作，真的），我们人类的乐观主义占了上风。估计几乎总是过于乐观。为了减少霍夫施塔特定律的影响，我们可以尝试尽可能客观地进行估计。写下关于项目的假设和事实清单。将每个清单元素标记为假设或事实，以使数据质量可见并管理预期。不要依赖直觉，因为每个人的感受都不一样。写下估算值，让你的大脑思考它们。将它们与其他人的估计进行比较，然后讨论差异。即便如此，它仍然只是一个估计，很可能不能反映现实。如果估算不是基于统计数据或其他历史数据，那么它的价值就非常低，因此与要求您估算的人一起管理预期总是好的——这总是会出错的。如果你让它尽可能客观，它就会减少错误。

康威定律

内容

康威定律指出，组织创建的任何系统都将类似于该组织的团队和沟通结构。如果你有10 个团队在一个系统上工作，你很可能会得到 10 个相互通信的子系统。

以上就是沈阳互助盘软件的小编给大家分享的内容，想要了解更多，欢迎来电咨询我们吧！