SOLID

即5大设计原则

  • Single Responsibility Principle，SRP
  • Open Closed Principle，OCP
  • Liskov Substitution Principle，LSP
  • Interface Segregation Principle，ISP
  • Dependence Inversion Principle，DIP

LOD

最少知道原则

KISS

Keep It Simple and Stupid.
Keep It Short and Simple.
Keep It Simple and Straightforward.
即”尽量保持简单“
KISS 原则是保持代码可读和可维护的重要手段。KISS 原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且，本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则。除此之外，同样的代码，在某个业务场景下满足 KISS 原则，换一个应用场景可能就不满足了。对于如何写出满足 KISS 原则的代码，参考下面几条指导原则：

  • 不要使用同事可能不懂的技术来实现代码；
  • 不要重复造轮子，要善于使用已经有的工具类库；
  • 不要过度优化。

    YAGNI

You Ain’t Gonna Need It。直译就是：你不会需要它。这条原则也算是万金油了。当用在软件开发中的时候，它的意思是：不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计。

Rule of Three:
我们在第一次写代码的时候，如果当下没有复用的需求，而未来的复用需求也不是特别明确，并且开发可复用代码的成本比较高，那我们就不需要考虑代码的复用性。在之后我们开发新的功能的时候，发现可以复用之前写的这段代码，那我们就重构这段代码，让其变得更加可复用。

DRY

Don’t Repeat Yourself。中文直译为：不要重复自己。将它应用在编程中，可以理解为：不要写重复的代码。这里说的重复指的是“实现逻辑重复、功能语义重复和代码执行重复。”

重复形式 症状 危害
实现逻辑重复
 功能和职责同样的代码写了多遍 浪费时间
功能语义重复 使用不同的代码实现了同一个功能多次
- 如前端开发时，两个同事分别按自己的开发风格对同一个组件实现了两次，然后各用各的。
- 如后端开发时，两个同事分别对同一工具类的功进行重复实现，然后各用各的。
 当需求发生变更时，需要保证重复的功能都被正确修改
代码执行重复 因设计不良，一个事务中，导致同一段代码被无意义地重复执行多次 徒增系统开销

高内聚、松耦合

High cohesion & Low coupling
“高内聚、松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。
所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中。所谓松耦合指的是，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。

理论六：我为何说KISS、YAGNI原则看似简单，却经常被用错？ 理论七：重复的代码就一定违背DRY吗？如何提高代码的复用性？