KISS（保持简单愚蠢）：
- 即使解决方案看起来很愚蠢，简单的解决方案也比复杂的解决方案好。
- 当解决方案使用较少的继承，较少的多态性，较少的类等时，解决方案会更好。
- 更简单的解决方案更易于维护，即检测和纠正缺陷更加有效。
YAGNI（您将不需要它）：
- 除非有必要，否则不要实施某些东西。
- 快速实现代码的最佳方法是少执行代码。减少错误的最好方法是减少代码。
做可能可行的最简单的事情：
- 首先，以您认为“可能可行”的最简单方式实现一项新功能。不要建立很多惊人的上层j架构，不要做任何花哨的事情，只需将其放入即可。甚至使用if语句。使代码通过新功能（以及所有功能，一如既往）的UnitTests。
- 其次，这对于规则至关重要，因此将系统重构为尽可能简单的代码，包括其现在具有的所有功能。遵循OnceAndOnlyOnce规则和其他代码质量规则，以使系统尽可能干净。
- 对于IterativeDevelopment的每次增量，都应该做可能会起作用的最简单的事情。为此，您必须至少知道两种执行此操作的方法。这样，您至少可以选择较简单的（如果不是最简单的话）。
关注点分离 ：
- 将计算机程序分成不同的部分，以便每个部分都解决一个单独的问题。
- 例如，应用程序的业务逻辑是一个问题，而用户界面是另一个问题。更改用户界面不应要求更改业务逻辑，反之亦然。
- 当关注点分开时，各个部分可以重复使用，也可以独立开发和更新。
- 将程序功能分成尽可能少的重叠的单独模块。
保持干DRY：
- 程序中的每个重要功能都应该在源代码中的一个位置实现。在类似的功能由不同的代码段执行的情况下，通常可以通过抽象出不同的部分将它们组合为一个代码，这通常是有利的。
- 复制（无意或有目的的复制）可能导致维护方面的噩梦，分解不佳以及逻辑上的矛盾。
- 修改系统的任何单个元素都不需要更改其他逻辑上不相关的元素。
- 另外，逻辑上相关的元素都可预测且一致地更改，因此保持同步。
- 仅将业务规则，长表达式，if语句，数学公式，元数据等放在一个位置。
- 确定系统中使用的每条知识的唯一且确定的来源，然后使用该来源生成该知识的适用实例（代码，文档，测试等）。
为维护编码：
- 迄今为止，维护是所有项目中最昂贵的阶段。
- 始终进行这样的编码：就像最终维护您的代码的人是知道您的住所的暴力心理变态者一样。
- 始终以这样的方式进行编码和注释：如果初级的一些人发现了一些密码，他们会很乐于阅读和学习。
避免过早优化：
- 在您需要进行优化之前，不要进行优化，只有在进行性能分析之后，您才发现优化瓶颈。
- 经过优化后，可能难以阅读并难以维护。
最小化耦合：
- 模块/组件之间的耦合是它们相互依赖的程度；耦合度越低越好。换句话说，耦合是在对代码单元“ A”进行未知更改后，代码单元“ B”将“中断”的概率。
- 消除，最小化和减少必要关系的复杂性。
- 通过隐藏实现细节，减少了耦合。
得墨meter耳定律：
- 不要跟陌生人说话。
- 通常会紧耦合
- 它可能会透露太多实施细节
- 对象的方法只能调用以下方法： 对象本身。 方法的参数。 在方法内创建的任何对象。 对象的任何直接属性/字段。
组合而不是继承
- 类之间的耦合较少。
- 使用继承，子类可以轻松地进行假设并打破LSP。
- 测试LSP（可替代性）以决定何时继承。
- 在存在“具有”（或“使用a”）关系时进行撰写，在“是a”的情况下进行继承。
正交性
- 正交性的基本思想是，在概念上不相关的事物不应在系统中相关。
- 它与简单性相关。设计越正交，例外就越少。
- 这样可以更轻松地学习，阅读和编写使用编程语言编写的程序。
- 正交特征的含义与上下文无关；关键参数是对称性和一致性。
稳健性原则
- 对自己的工作要保守一些，对别人所接受的事情要开放一些
- 为了能够发展服务，您需要确保提供商可以进行更改以支持新需求，同时最大程度地减少对现有客户的破坏。
- 向其他计算机（或同一计算机上的其他程序）发送命令或数据的代码应完全符合规范，但是，只要含义清楚，接收输入的代码应接受不合格的输入。
控制反转：
- 控制反转也被称为好莱坞原则，“不要打电话给我们，我们会打电话给您”。
- 它是一种设计原理，其中计算机程序的自定义编写部分从通用框架接收控制流。
- 控制反转具有很强的内涵，即可重用代码和特定于问题的代码是独立开发的，即使它们在应用程序中一起运行也是如此。
- 控制反转用于增加程序的模块化并使其可扩展。
- 可以使用Factory模式，Service Locator模式，依赖注入，上下文相关的查找，Template Method模式，Strategy模式来实现控制反转
最大化内聚性：
- 单个模块/组件的凝聚力是其职责形成有意义的单元的程度；凝聚力越高越好。
里斯科夫换人原则：
- LSP是关于对象的预期行为的。
- 程序中的对象应该可以用其子类型的实例替换，而不会改变该程序的正确性。
开/关原则：
- 软件实体（例如类）应为扩展而开放，但为修改而封闭。即，这样的实体可以允许在不更改其源代码的情况下修改其行为。
- 通过最小化对现有代码的更改来提高可维护性和稳定性。
- 编写可以扩展的类（与可以修改的类相反）。
- 仅暴露需要改变的运动部件，隐藏其他所有部件。
单一责任原则：
- 每个班级应负一个单一的责任，而该责任应由班级完全封装。责任可以定义为变更的原因，因此，一个类或模块应该只有一个变更原因。
- 可维护性：仅应在一个模块或一个类中进行更改。
隐藏实施细节：
- 软件模块通过提供接口来隐藏信息（即实现细节），并且不会泄漏任何不必要的信息。
- 当实现更改时，客户端使用的接口不必更改。
- 最小化类和成员的可访问性。
- 不要公开公开会员数据。
- 避免将私有实现细节放入类的接口中。
- 减少耦合以隐藏更多实现细节。
卷曲定律：
- 卷曲定律是关于为任何特定代码段选择一个明确定义的目标：做一件事情。
封装变化了什么：
- 好的设计可以识别最有可能发生变化的热点，并将其封装在API之后。然后，当发生预期的更改时，修改将保留在本地。
- 最小化发生变更时所需的修改
- 封装了API背后的概念
- 可能将变化的概念分成自己的模块
接口隔离原理：
- 将胖接口减少为多个更小，更具体的客户端特定接口。接口应该比实现它的代码更依赖于调用它的代码。
- 如果一个类实现了不需要的方法，则调用者需要了解该类的方法实现。例如，如果一个类实现一个方法而仅仅抛出一个方法，则调用者将需要知道实际上不应该调用此方法。
- 避免胖接口。类永远不必实现违反单一职责原则的方法。
童子军规则：
- 美国的童子军有一个简单的规则可以应用到我们的职业中：“让营地比您发现的要干净”。童子军规则指出，我们应始终将代码保留得比发现的干净。
- 在更改现有代码库时，代码质量趋于下降，从而增加了技术负担。遵循boyscout规则，每次提交时都应注意质量。不论大小，技术债务都会受到持续重构的抵制。
- 每次提交时，请确保它不会降低代码库的质量。
- 每当有人看到一些不尽如人意的代码时，他们都应该趁此机会在此位置进行修复。
命令查询分隔：
- 命令查询分离原则指出，每种方法都应该是执行操作的命令，或者是将数据返回给调用方的查询，但不能两者都是。提出问题不应修改答案。
- 有了这个原则，程序员可以更加自信地进行编码。由于查询方法不会改变状态，因此可以在任何地方以任何顺序使用。使用命令时，必须格外小心。
- 通过将方法清楚地分为查询和命令，程序员可以放心地编写代码，而无需了解每种方法的实现细节。
- 将每种方法实现为查询或命令
- 将命名约定应用于方法名称，这暗示该方法是查询还是命令
原文：https://www.jdon.com/55834
