1，KISS 原则（Simple and Stupid ）

KISS 原则即为让代码尽可能简单，目的是保持代码可读和可维护性

代码少不代表这符合KISS原则，当你使用复杂的正则表达式或lambda等开发技术，短短几行就实现了需求，但是可读性不一定好，不符合KISS原则

2，YAGNI原则（You Ain’t Gonna Need It）

YAGNI原则核心思想就是：不要做过度设计

不要去设计当前用不到的功能；不要去编写当前用不到的代码；代码可以根据业务留着扩展点，但是无需把还没用到的扩展也实现出来

YAGNI 原则跟 KISS 原则并非一回事儿。KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题（当前不需要的就不要做）。

3，DRY（Don’t Repeat Yourself）

YAGNI原则的目的是提高代码的复用性

代码重复可分为实现逻辑重复、功能语义重复、代码执行重复；实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则。实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则。除此之外，代码执行重复也算是违反 DRY 原则。

注释或者文档违反DRY：一个方法。写了好多的注释解释代码的执行逻辑，后续修改的这个方法的时候可能，忘记修改注释，造成对代码理解的困难。实际应用应该使用KISS原则，将方法写的见名知意，尽量容易阅读。注释不必过多。

此外：

提高代码可复用性的一些方法，有以下 7 点。

减少代码耦合；满足单一职责原则；模块化业务与非业务逻辑分离；通用代码下沉；继承、多态、抽象、封装；应用模板等设计模式

实际上，除非有非常明确的复用需求，否则，为了暂时用不到的复用需求，花费太多的时间、精力，投入太多的开发成本，并不是一个值得推荐的做法。这也违反 YAGNI 原则。（第一次编写代码的时候，我们不考虑复用性；第二次遇到复用场景的时候，再进行重构使其复用）

4，迪米特法则（The Least Knowledge Principle）

LOD应用于模块，类，目的是类关系实现松耦合。

所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。

LOD：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中的“有限知识”）。

LOD与单一职责和接口隔离很像，区别在于角度不一样：LOD侧重于类与类之间关系（能不依赖就不依赖，需要依赖也尽可能依赖抽象）；单一职责侧重于自身；接口隔离侧重于调用者

注：高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。（单一职责是实现代码高内聚非常有效的设计原则）

参考：设计模式之美