KISS 原则
KISS原则有以下三种经典的解释：
- Keep It Simple and Stupid.
- Keep It Short and Simple.
- Keep It Simple and Straightforward.
越底层封装成都越高、改动越少的模块可以更优先考虑性能，代码逻辑复杂可以接受。越上层改动越多的代码尽可能的要提升可读性。并非代码行数越少越好。
如何写出满足 KISS 原则的代码？
- 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
- 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
- 不要过度优化。不要过度使用一些奇技淫巧（比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。
YAGNI 原则
You Ain’t Gonna Need It
不要去设计当前用不到的功能；不要去编写当前用不到的代码，不要做过度设计。
比如，我们的系统暂时只用 Redis 存储配置信息，以后可能会用到
ZooKeeper。根据 YAGNI 原则，在未用到 ZooKeeper
之前，我们没必要提前编写这部分代码，我们可以预留好扩展点，等到需要的时候，再去实现
ZooKeeper 存储配置信息这部分代码。
KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题
DRY 原则
Don’t Repeat Yourself
实现逻辑重复、功能语义重复、代码执行重复。实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则。实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则。除此之外，代码执行重复也算是违反 DRY 原则。
代码复用性（Code Reusability）
区分三个概念：代码复用性（Code Reusability）、代码复用（Code Resue）和DRY原则。
怎么提高代码复用性？
- 减少代码耦合
- 满足单一职责原则
- 模块化
- 业务与非业务逻辑分离
- 通用代码下沉
- 继承、多态、抽象、封装
- 应用模板等设计模式
迪米特法则（LOD）
Each unit should have only limited knowledge about other units: only units “closely” related to the current unit. Or: Each unit should only talk to its friends; Don’t talk to strangers.
即：不该有直接依赖关系的类之间，不要有依赖
何为“高内聚、松耦合”？
所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。单一职责原则是实现代码高内聚非常有效的设计原则。
所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。前面讲的依赖注入、接口隔离、基于接口而非实现编程，以及迪米特法则，都是为了实现代码的松耦合。