一些流行的（software）开发原则目录表
| 原则名称 | 中文意译 |
|---|---|
| KISS | 尽量保持简单 |
| YAGNI | 不需要就不做 |
| Do The Simplest Thing That Could Possibly Work | 做最简单可行的事情 |
| Separation of Concerns | 职责分离 |
| Keep things DRY | 不要重复自己 |
| Code For The Maintainer | 为维护者编写代码 |
| Avoid Premature Optimization | 避免过早优化 |
| Minimise Coupling | 最小化耦合 |
| Law of Demeter | 迪米特法则 |
| Composition Over Inheritance | 组合优于继承 |
| Orthogonality | 正交性 |
| Robustness Principle | 鲁棒性原则 |
| Inversion of Control | 控制反转 |
| Maximise Cohesion | 最大化内聚 |
| Liskov Substitution Principle | 里氏替换原则 |
| Open/Closed Principle | 开闭原则 |
| Single Responsibility Principle | 单一职责原则 |
| Hide Implementation Details | 隐藏实现细节 |
| Curly's Law | 一次只做一件事 |
| Encapsulate What Changes | 封装变化 |
| Interface Segregation Principle | 接口隔离原则 |
| Boy-Scout Rule | 保持代码整洁 |
| Command Query Separation | 命令查询分离原则 |
| Murphy's Law | 墨菲定律 |
| Brooks's Law | 布鲁克斯定律 |
| Linus's Law | 邓斯特菲定律（大眾智慧定律） |
KISS
大多数系统如果保持简单，而不是变得复杂，效果最好。
为什么？
更少的代码需要更少的时间来编写，错误更少，并且更容易修改。 简单是最终的复杂。 似乎完美不是在没有什么可以添加的时候，而是在没有什么可以拿走的时候。 保持简单（KISS）
YAGNI
YAGNI代表“你不需要它”：在必要之前不要实施某些东西。
为什么？
任何仅用于明天需要的功能的工作，意味着失去当前迭代需要完成的功能的工作量。 它导致代码膨胀；软件变得更大、更复杂。
怎么知道？
总是在你真正需要的时候实施它们，而不是当你只是预见到你需要它们的时候。
Do The Simplest Thing That Could Possibly Work
做最简单的可能有效的事情
为什么？
解决实际问题的真正进展是最大化的，如果我们只解决真正的问题是什么。
怎么知道？
问问你自己：“最简单可行的方法是什么？”
Separation of Concerns
关注点分离是一种设计原则，用于将计算机程序分成不同的部分，这样每个部分都处理一个单独的关注点。例如，应用程序的业务逻辑是一个关注点，用户交互界面是另一个关注点。更改用户交互界面不需要更改业务逻辑，反之亦然。
埃兹格·W·迪克斯特拉 (1974):
这就是我有时所说的“关注点分离”。据我所知，这是有效整理一个人思想的唯一可用技巧，即使不完全可能。这就是我所说的“将注意力集中在某个方面”的意思：这并不意味着忽视其他方面，它只是公正地对待这样一个事实，即从这个方面的角度来看，另一个方面是无关紧要的。
为什么？
简化软件应用程序的开发和维护。 当关注点分离良好时，可以重用各个部分，以及独立开发和更新。
怎么知道？
将程序功能分解为尽可能少重叠的单独模块。
Keep things DRY
程序中的每一个重要功能都应该在源代码中的一个地方实现。如果相似的功能由不同的代码片段执行，通常通过抽象出不同的部分将它们组合成一个是有益的。
为什么？
复制（无意或有目的的复制）会导致维护噩梦、保理不佳和逻辑矛盾。 对系统的任何单个元素的修改不需要更改其他逻辑上不相关的元素。 此外，逻辑上相关的元素都可预测且一致地变化，因此保持同步。
怎么知道？
将业务规则、长表达式、if语句、数学公式、元数据等只放在一个地方。 识别系统中使用的每条知识的单一、明确的来源，然后使用该来源生成该知识的适用实例（代码、留档、测试等）。 应用三法则.
不要重复你自己的代码。
干燥原理
抽象原理
一次且仅此一次是DRY的子集（也称为重构目标）。
小心代码指标“重复行”
Code For The Maintainer
为维护者编写代码
为什么？
维护是迄今为止任何项目中最昂贵的阶段。
怎么知道？
成为维护者。
始终编写代码，就好像最终维护你的代码的人是一个想知道你住在哪里的暴力精神病患者。
始终以这样一种方式编写代码和注释，即如果比他小几个等级的人拿起代码，他们会乐于阅读和学习它。
不要我觉得.
使用最小惊讶原则.
Avoid Premature Optimization
在需要之前不要优化，只有在分析之后，您才会发现瓶颈优化它。
Minimise Coupling
模块/组件之间的耦合是它们相互依赖的程度；低耦合更好。换句话说，耦合是代码单元“B”在代码单元“A”发生未知变化后“断裂”的概率。
为什么？
一个模块的变化通常会迫使其他模块的变化产生连锁反应。
由于模块间依赖性的增加，模块的组装可能需要更多的努力和/或时间。
特定模块可能更难重用和/或测试，因为必须包含依赖模块。
开发人员可能害怕更改代码，因为他们不确定可能会受到影响。
怎么知道？
消除、最小化和降低必要关系的复杂性。 通过隐藏实现细节，减少了耦合。 应用LoD原则。
Law of Demeter
不要和陌生人说话。
为什么？
它通常会收紧联轴器
它可能会透露太多的实现细节
怎么知道？
对象的方法只能调用以下内容：
对象本身。
方法的参数。
在方法中创建的任何对象。
对象的任何直接属性/字段。
Composition Over Inheritance
组合优于继承
为什么？
类之间的耦合更少。 使用继承，子类很容易做出假设，并破坏LSP。
怎么知道？
测试LSP（可替代性）以决定何时继承。 当有“有”（或“使用”）关系时编写，当“是”时继承。
Orthogonality
Orthogonality（正交性）的基本思想是，概念上不相关的事物在系统中不应该相关。
它与简单有关；设计越正交，异常越少。这使得用编程语言学习、阅读和编写程序变得更容易。正交特征的含义与上下文无关；关键参数是对称性和一致性。
Robustness Principle
鲁棒性原则
Inversion of Control
控制反转
Maximise Cohesion
最大化内聚
Liskov Substitution Principle
里氏替换原则
Open/Closed Principle
开闭原则
软件实体（例如类）应该对扩展开放，但对修改关闭。这样的实体可以允许在不更改其源代码的情况下修改其行为。
为什么？
通过最小化对现有代码的更改来提高可运维性和稳定性。
怎么知道？
编写可以扩展的类（与可以修改的类相反）。 只暴露需要改变的活动部分，隐藏其他所有内容。
Single Responsibility Principle
（单一职责原则）一个类永远不应该有不止一个更改的理由。
长解释：每个类都应该有一个单一的责任，这个责任应该完全由类封装。责任可以定义为改变的理由，所以一个类或模块应该有一个，而且只有一个改变的理由。
为什么？
可维护性：应该只需要在一个模块或类中进行更改。
怎么知道？
应用卷毛定律。
Hide Implementation Details
（隐藏实现细节）软件模块通过提供接口隐藏信息（即实现细节），不会泄露任何不必要的信息。
为什么？
当实现发生变化时，客户端使用的接口不必改变。
怎么知道？
最小化类和成员的可访问性。 不要公开暴露会员数据。 避免将私有实现细节放入类的接口中。 减少耦合以隐藏更多实现细节。
Curly's Law
卷毛定律是关于为任何特定的代码选择一个单一的、明确定义的目标：做一件事。
卷毛定律：做一件事
Encapsulate What Changes
封装变化
一个好的设计可以识别最有可能更改的热点并将它们封装在API后面。当预期的更改发生时，修改将保留在本地。
为什么？
在发生更改时最小化所需的修改
怎么知道？
封装API背后变化的概念 可能将变化的概念分离到它自己的模块中
Interface Segregation Principle
（接口隔离原则）将胖接口简化为多个更小、更具体的客户端特定接口。接口应该比实现它的代码更依赖于调用它的代码。
为什么？
如果一个类实现了不需要的方法，调用者需要知道该类的方法实现。例如，如果一个类实现了一个方法，但只是抛出，那么调用者需要知道这个方法实际上不应该被调用。
怎么知道？
避免胖接口。类永远不应该实现违反单一责任原则的方法。
Boy-Scout Rule
（童子军规则）美国童子军有一条简单的规则，我们可以应用于我们的职业：“让露营地比你发现的更干净”。童子军规则规定，我们应该永远让代码比我们发现的更干净。
为什么？
当对现有代码库进行更改时，代码质量往往会下降，从而积累技术债务。遵循童子军规则，我们应该注意每次提交的质量。技术债务受到持续重构的抵制，无论多小。
怎么知道？
确保每次提交不会降低代码库质量。 每当有人看到一些代码不那么清晰时，他们应该抓住机会立即修复它。
Command Query Separation
命令查询分离原则指出，每个方法都应该是执行操作的命令或向调用者返回数据的查询，但不能两者兼而有之。提出问题不应修改答案。
有了这个原则，程序员可以更有信心地编码。查询方法可以在任何地方以任何顺序使用，因为它们不会改变状态。对于命令，必须更加小心。
为什么？
通过将方法清楚地分离为查询和命令，程序员可以更加自信地编码，而无需了解每个方法的实现细节。
怎么知道？
将每个方法实现为查询或命令 将命名约定应用于暗示方法是查询还是命令的方法名称
Murphy's Law
（墨菲定律）任何可能出错的事情都会出错。
这似乎是一个普遍的定律，当有最小的可能性出错时，它最终会出错。当我们考虑概率和无限量的试验时，这是完全有意义的。该定律也适用于软件开发。
Brooks's Law
（布鲁克斯定律）在后期软件项目中增加人力会使其变得更晚。
该定律与软件项目管理有关，由弗雷德·布鲁克斯在他的著名著作《人月神话》中介绍。该定律的本质是，向软件项目添加新开发人员不会使他们立即提高生产力，相反，由于沟通开销，会占用其他团队成员的时间。
Linus's Law
只要有足够的眼球，所有的错误都是浅薄的。
该法律源于Eric S. Raymond的《大教堂和集市》一书，是为了纪念芬兰著名的Linux操作系统发明者Linus Torvalds而命名的。这基本上是对软件审查过程的赞扬，在接受和合并代码之前，多个开发人员会检查一段代码。
本文正在参加「金石计划」
