这篇介绍性文章讨论了软件开发人员在开发任何软件时必须牢记的事项。它还讨论了每天编写代码时应考虑的一些关键原则。
概述：
让我们从一个问题开始这个话题–在软件开发的背景下，什么被认为是一个好的设计?
大多数人认为此问题没有特定答案！但是在设计时要强调的一点是，软件的开发和维护的成本和时间应该最小化，更重要的是维护。由于IT行业对软件进行了大量改进和升级，因此，如果最小化更改设计的成本和时间，那么可以说这是一个好的设计。原因是执行更新和推动更新/升级的速度快且成本低。
尽管对于一个好的设计来说这可能是一个好方法，但是与此相关的还有一个问题，那就是当需要更改设计时，它意识到更改设计为时已晚。因此，现在又有一个问题仍然是什么才算是一个好的设计?
为了更好地回答这个问题，让我们开始对设计进行调整，看看设计如何站起来?如果没有，那么让我们不断发展，靠近更容易更改的地方，这是迄今为止许多经验丰富的开发人员所做的事情。因此，软件开发设计原则是由经验丰富的开发人员提供的一组特定准则，这些准则是他们在软件开发阶段从错误中学到的。
It is almost impossible to get a good design for very first time.
设计原则 ：
到目前为止，本文讨论的是对良好设计概念的理解。现在，让我们详细介绍可用于良好设计的准则集。
1.保持简单，愚蠢(KISS)原则：
这是第一个原则，首字母缩写词代表“保持简单，愚蠢” 。其他著名的替代首字母缩略词是
- 保持愚蠢。
- 保持简短和简单。
- 保持简单明了。
- 保持简单和智能。
它建议不要在代码中涉及复杂性，并尝试尽可能避免复杂性。这是因为编写了更复杂的代码，在以后的任何时间修改它都变得更加困难。爱因斯坦( Albert Einstein)所说的话说得很好，这将使上面所说的内容得到开绿灯-如果您无法解释，则说明不够充分。因此，简单性应该是我们设计软件的主要目标。
上图清楚地表明，KISS的原则目标是通过使事情尽可能简单和使用最简单的解决方案(例如直线路径)来实现目标，而不是通过使事情变得复杂和来回挣扎来实现目标。
违反KISS的示例–
无论是在编程生涯的早期还是在编程旅程中的某个地方，都可能经历过他/她编写了凌乱的代码的情况。这里的凌乱代码意味着在一个块，方法或类中编写多个问题的解决方案。这可能会导致在代码中添加一些不必要的行。可能还会存在一个问题可能有多种解决方案的情况。例如，在某些情况下，switch语句和if-else语句都提供了解决问题的方法。现在，基于上下文，需要选择使用哪个，哪个是更简单的解决方案。当然，这只是出于说明目的的简单示例。但是在日常的编程和开发生活中，人们遇到了许多这样的问题。需要暂停一下才能正确思考并明智地选择解决方案。
The task of software development team is to engineer illusion of simplicity. – Grady Booch
吻的好处–
- 它有助于快速解决问题。
- 由于解决方案很简单，因此有助于维护代码。
- 它提供了修改或重构代码的灵活性。
- 它提供了发烧代码行中复杂问题的解决方案。
- 最后，它提供了高质量的代码。
2.您将不需要它(YAGNI)原理：
YAGNI代表您将不需要它。这意味着，如果以后不方便使用，请不要立即使用。作为一名程序员，开发人员通常会执行很多他们真正不需要的东西。实施现在根本不需要的东西，将始终消耗成本，时间和精力。因此，将材料推迟到将来一直是一个好习惯，而今天并不需要。简而言之，YAGNI只是说不要真正做某事，直到您真正发现这样做的价值为止。
该原理在极限编程(XP)之后起作用，但是它适用于所有类型的软件开发过程和方法。实施YAGNI可以节省时间并有效地交付项目。简而言之，该原理不利于开发目前不需要的任何功能。这样开发人员可以节省时间并专注于代码的其他部分或组件。
3.干法原理：
程序员通常会无意或无意间编写大量重复的代码。这个原则迫使我们避免这种习惯。它说不要重复自己。这意味着，系统中的每条知识都应具有唯一且明确的表示形式。程序员可以使用CPD和Simian等工具来消除重复代码。 CPD代表复制粘贴检测器。而且，猿猴的意思是猴子，它自然地复制了一件东西。
违规示例–
程序员以许多方式一次又一次地重复代码。一些示例可能是为每个赋值和初始化声明了过多的局部变量。一次又一次地为同一任务编写多个方法和类。考虑一种情况，其中一种方法被编写在服务或数据层之外，以从存储库中获取一组用户数据，并且需要对该组应用一些过滤。现在，如果另一层中存在相同类型的需求，则需要再次编写逻辑，因为该层无法从该层访问。通常，这种任务驻留在服务/数据层中。这样，只要存在相同类型的需求，就可以调用该服务或层的相关方法。
如何避免干燥–
为避免干燥，请遵循以下几点。
- 重用您的代码，永远不要重复
- 遵循命名约定，并为方法，变量，类和对象等分配明确的名称。
- 在适当的层，位置和服务中编写代码
笔记 –
遵循命名约定并将代码添加到正确的位置有助于识别代码中的重复项。
4. SOLID原则：
SOLID是以下设计原则集的结合，并且从此处取了它的助记词缩写。
- 单一责任原则
- 开/关原则
- 里斯科夫替代原则
- 接口隔离原理
- 依赖倒置
5.单一责任原则(SRP)：
该原则表明，我们的代码本质上应该具有凝聚力。在这里，凝聚力意味着应该集中，狭窄，并且只做一件事情，并且只做好一件事情。反过来，这意味着具有凝聚力的代码无需承担很多责任，而只专注于做一件事。在面向对象设计的背景下，可以说一类应该只承担一个责任，这样就不必频繁地进行更改。
If a code is cohesive, it has one, and only one, reason to change.
因此，如果有一段代码可以完成多项任务，那么该模块就必须不断更改，这会增加成本，因为当程序员进行更改时，他必须确保所做的更改不会破坏其他功能，并且确实会受影响，并且变得非常昂贵。另一方面，将一段代码分解为几段，每段代码只能完成一件事情并且只能完成一件事情，那么更改该段代码的成本就容易得多。
笔记 –
当它说“一段代码”时，将其视为类，方法或函数。违反单一责任原则会增加程序员的难度，并且变得难以测试，阅读，记忆和重用代码。
6.开放/封闭原则(OCP)：
该原则表示应该打开一段代码(通常是类，模块或组件)以进行扩展，而关闭则进行修改。这意味着应该以准备采用/添加新功能但不对任何修改感兴趣的方式编写类，方法或函数。在面向对象设计的背景下，可以通过抽象和多态的概念来实现。
7. Liskov替代原则(LSP)：
该原理说，使用父类的引用的函数也必须能够在不知道子类的情况下使用子类的对象。这意味着可以使用超类类型的方法必须能够与派生类的对象一起使用而没有任何问题。
基类的用户应该能够使用派生类的实例，而无需了解它们之间的区别。
8.接口隔离原理(ISP)：
这个原则说，如果客户不需要某个接口，则不应强迫他们实现该接口。当接口包含多个功能且客户端只需要一个函数而不是全部时，通常会发生这种情况。在这种情况下，客户端将被强制实现该接口的所有功能。这太疯狂了，应该避免。
因此，必须始终保持界面的凝聚力和狭窄性，并专注于一件事和一件事。
9.依赖倒置或依赖注入(DI)：
这个原理是关于耦合的。耦合是事物之间的连通度，即您的代码如何相互连接。这里要记住的关键点是，当我们的代码正在与其他代码交谈时，它总是会增加耦合。简而言之，耦合取决于我们的代码所依赖的东西。一个很好的例子是传统的基于类的继承。
继承实际上增加了耦合。现在，按照此原则，在可能的范围内删除或最小化依赖关系。如果无法删除所有依赖关系，则至少将其最小化，这称为松散耦合。在面向对象设计的上下文中，依赖于一个类称为紧密耦合，而依赖于一个接口则称为松散耦合。
一个好的设计总是以高内聚力和松散的耦合结束
此原理与OCP原理协同工作，为避免违反OCP，请使用依赖项反转原理。像Spring这样的面向依赖注入的框架是该原理的真实示例和实现
审查 –
这不是设计原则，而是许多开发人员或公司遵循的良好做法。一旦完成软件或组件的开发，在将其推进到下一个阶段之前，必须先进行代码审查过程。您团队中的任何人都可以进行此审核。
Remember that humans are quick to judge others faults, but never point out their own.
一旦对其进行了审核并提供了审核意见，请远离我们的自我并进行查看，并根据需要进行更改。
结论 ：
以上是一些经过高度讨论的设计原则，这些原则非常重要，可以帮助我们避免重复代码，减少工作量，并帮助我们将复杂性降至最低。因此，无论何时开发软件或软件组件，都可以在我们的日常编码生活中应用这些原则。在设计和开发过程中与同事或团队成员讨论这些原则也是一种很好的做法，因此，如果您遗漏了任何原则或违反了这些原则，则将在早期阶段指出这些原则，而不是将其付诸实践。后期失误。