- 里面涉及到对一些定律、原则以及模式的解释，但不提倡其中任何一个。它们的应用始终存在着争论，并且很大程度取决于你正在做什么。
- 劣质代码可能会影响后续优化的效率，从而进一步造成代码劣化；随着时间的推移，这种效应将会导致代码质量大幅下降。
- 设计高度复杂的系统很可能会失败。它们很难一蹴而就，更多是从简单的系统逐渐演变而来。
- 一个行为所产生的消极结果并不是恶意。相反，消极结果更有可能归咎于这些没有得到充分理解的行动或影响。
- 即使考虑到侯世达定律，它也总是比你预期的要长。
- 对一个系统的改进会导致其他部分的恶化；或者它会将其他的恶化隐藏起来，并导致系统整体状态的退化。
- 过早优化是万恶之源。
- 该定律表明，软件的一个单元应该只与其直接合作者交谈。
- 比如对象
A引用了对象B，对象B引用了对象C，则A可以直接调用B的方法，但不应直接调用C的方法。所以如果C有一个doThis()的方法，A不应该直接调用，而是使用B.getC().doThis()。
- 原则通常是与设计相关的准则。
- 所有的系统模型都是有缺陷的，但只要它们没有太多的缺陷，那便有可能是有用的。
- 设计者必须依据适当的细节程序来建模。过多的细节可能会导致太高的复杂度，过少的细节可能会使模型无法正常工作。
- 程序的每一行最初都是出于某种原因编写的，因此根据切斯特森围栏原则，在更改或删除代码之前，即使看起来似乎是多余的或不正确的，也应该尝试完全理解代码的上下文和含义。
- 这是一个缩写。它代表了五个面向对象设计原则，这些原则旨在使软件系统更易于维护和扩展。
- 这个原则表明模块或者类只应该做一件事。实际上，这意味着对程序功能的单个小更改，应该只需要更改一个组件。
- 软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。这意味着软件实体应该允许在不修改其源代码的情况下进行扩展。
- 子类型必须能够替换掉它们的基类型。这意味着，如果类
B是类A的子类，那么B的实例应该能够在任何需要A实例的地方使用，而不需要更改任何代码。
- 客户端不应该被迫依赖它们不使用的方法。这意味着应该将大型接口拆分为更小、更具体的接口。
- 高级模块不应该依赖于低级模块，两者都应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
- 极限编程原则告诫开发人员，他们应该只实现当前所需的功能，并避免实现未来需要的功能，仅在必要时才实现。