好的软件工程原则

关注

发布于: 2020 年 05 月 28 日

让我们来看看这些基本的建议。 下面的一些原则是特定于 python 的，但大多数不是。
量两次，切一次(Measure twice and cut once)   如果你只能从这篇文章中学到一个原则且最重要的一个，那么就是这个。 开发人员，架构师和经理人经常因为个人情绪、以及其他问题而难以集中注意力。 就工程师来说，这个原则意味着选择正确的解决方案，选择正确的方法来解决问题，选择正确的工具来解决问题，对建立的解决方案必须充满信心。 选择这里意味着投入一些思考，找到必要的资源，组建合适的团队，思考设计，思考方法，设定任务，控制结果，并为此承担责任。 这就是“活在当下”。 我认为我自己还没有准备好用正确的词汇来描述它。
不要重复自己(Don't Repeat Yourself)  这是一个相当简单但非常有用的原则，它说在不同的地方重复同样的事情是非常糟糕的。 首先，它涉及到进一步支持和修改代码的必要性。 如果某个代码片段在程序中的几个地方被复制，那么很有可能出现两种灾难性的情况:    
 当对源代码进行哪怕是很小的改动时，您需要在几个地方更改相同的代码。 这需要额外的时间、精力和注意力，而这件事件通常也非常不容易。
第一项紧随第二项。 团队中的其他开发人员可能会意外地错过其中一个更改(只合并了控制系统中的分支) ，并将面对应用程序中随后出现的一系列错误。 这些 bug 可能会让您感到沮丧，因为您已经听说这样的 bug 似乎已经被修复了。  
在这方面，有一个建议ーー如果在清单中发现任何代码超过两次，则应以单独的方式来处置。 这是通用做法。 事实上，即使再次遇到重复的bug，您也应该考虑创建一个单独的方法。  
奥卡姆剃刀(Occam’s Razor)  这是一个非常普遍的想法，它来自于哲学编程。 这个原则得名于奥克姆的英国修道士威廉。 这一原则表明: ”没有必要，不得增加实体”。 在工程学中，这一原则被解释为: 没有必要创建不必要的实体。 因此，首先考虑添加另一个方法 / 类 / 工具 / 流程等的好处不见得总是一个好主意。 毕竟，如果您添加了另一个方法 / 类 / 工具 / 流程等等，除了增加复杂性之外，您没有得到任何其他好处，那还有什么意义呢？
保持足够简单(Keep It Simple Stupid )  这是一个与上面非常类似的原则，但它的含义略有不同。 这个原则要求代码必须尽可能简单，不能有复杂的结构，否则会使代码的调试和维护复杂化。 此外，对于另一个程序员来说，理解代码的逻辑将会更加困难，这反过来也将需要额外的时间和精力。 这就是为什么您应该始终尝试使用简单的构造来尽可能多地解决问题，而不需要使用大量的分支、深层嵌套和过度重载的类结构。 通过这样做，你将使自己和同事的生活更加轻松，因为复杂性会产生错误。 记住 Peter Hintiens 说过的话: “简单永远比功能好”。  
你不会需要它（You Aren’t Gonna Need It ）  这是许多程序员都会遇到的问题。 从项目一开始就希望立即实现所有必要的(有时甚至是不必要的)功能。 也就是说，当开发人员从一开始就将所有可能的方法添加到类中并实现它们时，甚至可能在未来永远不会使用它们。 因此，根据这个建议，首先，只实现您需要的东西，然后，如果必要的话，再扩展相应功能。 这样，您就可以节省调试代码的工作量、时间以及精力，而实际上这些代码却并不需要。
前期大设计(Big Design Up Front)在开始开发功能之前，您应该首先考虑应用程序架构，并将整个系统设计为足够小的细节，然后才按照预定义的计划进行实现。 原则是有存在的权利的，但是最近，它受到了相当多的批评。 这首先与设计和制定过程中的方案陈旧有关。 在这方面，仍然有必要进行后续的修改。 但它也具有不可否认的优点，在正确的设计中，可以大大降低进一步调试和纠错的成本。 此外，这样的信息系统，作为一个规则，更简洁的架构是正确的。  
避免过早优化(Avoid Premature Optimization)  “过早的优化是编程中所有问题(或者至少是大部分问题)的根源” -- Donald Knuth
优化是加快程序运行速度，降低系统资源消耗的一个非常正确和必要的过程。 但是每件事都有它自己的时机。 如果在开发的早期阶段进行优化，可能弊大于利。 首先，它与这样一个事实相关，即优化代码的开发需要更多的时间和精力用于开发和支持。 在这种情况下，您通常必须首先检查所选择的开发方法的正确性。 这就是为什么一开始使用一个简单但不是最优的方法更有利可图。 稍后，在估计这种方法会降低应用程序的工作速度时，可以使用一种更快或更少资源密集型的算法。 此外，只要你最初实现了最优的算法，需求就可能改变，代码就会变成垃圾。 因此，没有必要在过早的优化上浪费时间。
## 最小惊奇原则(Principle Of Least Astonishment)    
这个原则意味着您的代码应该是直观和明显的，并且在检查代码时不会让其他开发人员感到惊讶。 例如，如果这个方法被称为“ making cookies” ，但是结果是得到了土豆，那么这段代码就是不好的(很明显)。 此外，如果无法避免副作用，应尽量避免副作用，并将副作用记录在案。
S.O.L.I.D.  “SOLID”实际上是一组面向对象设计原则。 “ SOLID”中的每个字母代表一个原则，它们是:  
<u>单一责任（Single responsibility）:</u>    
声明每个模块或类应该对软件提供的功能的一个部分负责，并且这个责任应该完全由类封装;
<u>开闭原则（Open-closed): </u>   
声明软件实体(类、模块、功能等)应该对扩展开放，但对修改关闭;  
 <u>李斯科夫替换(Liskov substitution)</u>  
声明继承的类应该补充而不是替换基类的行为;
<u>界面隔离(Interface segregation)</u>  
声明任何客户端都不应该被迫依赖于它不使用的方法;  
<u>依赖反转(Dependency inversion)</u>  
程序员应该在接口层而不是在实现层工作  
当一起应用时，这些原则可以帮助开发人员创建易于维护和扩展的代码。  
Demeter定律  该原则的基本思想是在类之间划分职责区域，并将逻辑封装在类、方法或结构中。 可以从这一原则中区分出若干建议:  
类或实体应该是独立的
你应该尝试减少不同类之间的连接数量(所谓的coupling 耦合)  
关联的类必须在一个 module / package / 目录中(也称为cohesion 凝聚力.）  
遵循这些原则，应用程序变得更加灵活、易于理解和易于维护。
总结  同胞们，让我们成为伟大的工程师吧！ 让我们考虑一下设计和构建健壮且实现良好的系统，而不是成长中的有机怪物。 列举的原则在本质上是高度相关和联系的。 当然，我没有创造它们，但是一个小小的提醒也不会伤害到我，至少我是健忘的。
 参考：  - What Are The Best Software Engineering Principles?  
- 工程效能提升  
- 我的十年
﻿