最佳软件工程原则是什么？

软件开发原则——它是一系列具体的规则和建议，工程师在程序实现过程中，如果想要编写出美观、易懂且易于维护的代码，就需要遵循这些规则和建议。没有什么神奇的魔杖，能让你把变量、类和函数的混合体转换成理想的代码，但有一些技巧和提示，可以帮助工程师确定自己是否做得正确。

让我们来看看这些基本建议。以下一些原则是针对 Python 的，但大多数并非如此。

三思而后行

我认为这是所有原则中最重要的。如果你只从这篇文章中学习一个原则——那就应该是这个。我们， 开发人员/devops/架构师/经理人们总是因为注意力不集中、愚蠢的错误和打字错误、个人问题、糟糕的心情和冰冷的咖啡而苦恼。这些都不重要——你需要解决问题。对我这个工程师来说，这条原则意味着选择正确的问题来解决，选择正确的方法，选择正确的工具来解决问题，以及对解决方案的信心。

但这种自信不能仅仅源于代码本身，它应该源于各种测试，源于频繁运行代码，源于为问题构建正确的解决方案等等。这就是工程的本质。我想我自己还没准备好用合适的语言来描述它。

不要重复自己（DRY）

这是一个非常简单但非常有用的原则，它表明在不同的地方重复相同的代码是一个坏主意。这主要是因为需要进一步维护和修改代码。如果某个代码片段在程序中的多个地方重复，那么很有可能出现两种灾难性的情况：

1. 即使对源代码进行微小的修改，也需要在多个地方修改相同的代码。这将需要额外的时间、精力和注意力（有时这并不容易）。
2. 第一项之后是第二项。您或您团队中的其他开发人员可能会意外错过其中一项修复，从而导致应用程序出现后续错误。这些错误可能会令人沮丧，因为您听说类似的错误已经被修复了。

对此，有一条建议：如果任何代码在清单中出现超过两次，则应将其放在单独的方法中。这只是一个一般性建议，实际上，即使第二次遇到重复，您也需要考虑创建一个单独的方法。

样式="display:block; text-align:center;"
data-ad-layout="in-article"
data-ad-format="fluid"
data-ad-client="ca-pub-4665632381152577"
data-ad-slot="7970039881">

奥卡姆剃刀

这是一个非常普遍的理念，它源于哲学，并被引入到编程中。该原则得名于英国僧侣奥卡姆的威廉。该原则指出：“如无必要，勿增实体”。在工程学中，该原则的解释是：无需创建不必要的实体。因此，你始终需要首先考虑添加方法/类/工具/流程等带来的益处。毕竟，如果你添加方法/类/工具/流程等，除了增加复杂性之外没有任何好处，那还有什么意义呢？

保持简单愚蠢（KISS）

这条原则与上一条非常相似，但含义略有不同。这条原则指出，代码应该简洁，尽可能避免任何复杂的结构，否则会使代码的调试和维护过于复杂。此外，其他程序员理解代码逻辑也会更加困难，这反过来又会耗费额外的时间和精力。因此，请始终尝试使用尽可能简单的结构来解决问题，避免使用大量的分支、深度嵌套和过度设计的类结构。这样做可以简化您自己和同事的工作，因为复杂性会滋生错误。记住 Pieter Hintjens 的名言：“简单永远比功能性更好。”

你不需要它（YAGNI）

很多程序员都面临一个问题：在开发过程的一开始就想一次性实现所有必要的（有时甚至是不必要的）功能。也就是说，开发人员从一开始就将所有可能的方法添加到类中并实现它们，而将来甚至可能根本不会用到它们。因此，根据此建议，首先只实现你需要的功能，以后如果需要，再添加功能。这样，你就可以节省调试那些不真正需要的代码的精力、时间和精力。

预先进行大型设计

在开始开发功能之前，必须首先思考应用程序架构，并设计整个信息系统，直至相当细微的细节，然后才能按照先前制定的计划进行实施。这一原则理应存在，但最近却遭到了不少批评。这主要是因为在设计和开发过程中，方案已经过时。因此，您仍然需要进行后续修改。但它也具有无可辩驳的优势，通过合理的设计，您可以显著降低进一步调试和修复错误的成本。此外，这样的信息系统通常更加简洁，架构也更加合理。

避免过早优化

“过早优化是编程中所有罪恶的根源（或至少是大部分罪恶的根源）” - Donald Knuth

优化是一个非常正确且必要的过程，它可以加快程序的运行速度，并减少系统资源的消耗。但凡事都有其时机。如果在开发的早期阶段进行优化，则弊大于利。这主要是因为优化代码的开发需要开发人员投入更多的时间和精力，而且可能更加复杂。在这种情况下，通常需要首先验证所选开发方法的正确性。因此，一开始使用简单但并非最优的方法更有利。之后，在评估这种方法对应用程序运行速度的影响程度后，再转向更快或资源占用更低的算法。此外，在您最初实施最优算法的期间，需求可能会发生变化，代码可能会被丢弃。因此，没有必要在过早的优化上花费时间。

最小惊讶原则

这条原则意味着你的代码应该直观易懂，并且在代码审查时不会让其他开发人员感到意外。例如，如果方法调用了“制作饼干”，但结果却得到了一个土豆，那么这段代码显然是错误的。

样式="display:block; text-align:center;"
data-ad-layout="in-article"
data-ad-format="fluid"
data-ad-client="ca-pub-4665632381152577"
data-ad-slot="7970039881">

坚硬的

“ SOLID ” 实际上是一组面向对象的设计原则。“ SOLID ”中的每个字母代表一条原则，具体如下：

• 单一职责规定每个模块或类应该对软件提供的单一功能部分负责，并且该职责应该完全由该类封装；
• 开放-封闭是指软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭；
• 里氏替换指出继承的类应该补充而不是取代基类的行为；
• 接口隔离规定任何客户端都不应被迫依赖于它不使用的方法；
• 依赖倒置表示程序员应该在接口级别工作，而不是在实现级别工作。

当结合应用这些原则时，可以帮助开发人员创建易于维护和扩展的代码。

迪米特法则

该原则的核心思想是在类之间划分职责范围，并将逻辑封装在类、方法或结构中。基于这一原则，我们可以提出几点建议：

1. 类或实体应该是独立的
2. 需要尝试减少不同类之间的连接数（又称耦合）
3. 相关类应该位于同一个模块/包/目录中（又称凝聚力）

通过遵循这一原则，应用程序变得更加灵活、易理解和易维护。

结论

各位开发者，让我们一起成为工程师吧！让我们专注于设计和构建健壮且实现良好的系统，而不是培育有机怪物。列出的原则本质上是高度相关的，并且相互关联。当然，这些原则并非我创造的，但提醒一下也无妨，至少我的记忆力并非完美无缺。

感谢您的阅读！

有任何问题吗？请在下方留言，开启精彩讨论！

看看我的博客，或者在推特上跟我打个招呼👋 ，或者订阅我的电报频道。
制定你的最佳计划！