by emanjusaka from https://www.emanjusaka.top/2023/08/design-patterns-code-standard-principle 彼岸花开可奈何

本文欢迎分享与聚合，全文转载请留下原文地址。

前言

形容代码写得好我们经常用好代码、优秀的代码；形容不好的代码我们就说是屎山、垃圾。如果让我们说出这代码到底好在哪？坏在哪？我们可能就哑口无言了。那评价代码好坏的标准有哪些？我们可以从哪些维度去评价一个代码的好坏呢？下面我给出一些评价代码的标准和一些基本的设计原则。

1、代码质量评价标准

• 可维护性（maintainability）

  “代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码。

  “代码不易维护”就是指，修改或者添加代码需要冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。

• 可读性（readability）

  任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。

• 可扩展性（extensibility）

  代码的可扩展性表示，我们在不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码。

• 灵活性（flexibility）

  如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得比较灵活。

• 简洁性（simplicity）

  尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护。我们在编写代码的时候，往往也会把简单、清晰放到首位。

• 可复用性（reusability）

  尽量减少重复代码的编写，复用已有的代码。

• 可测试性（testability）

  代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。

其中比较常用的三个标准是：可维护性、可读性、可扩展性。

2、设计原则

• SRP 单一职责原则

  一个类或者模块只负责完成一个职责（或者功能）

• OCP 开闭原则

  软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

• LSP 里式替换原则

  • 子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。

  • 子类在设计的时候，要遵守父类的行为约定（或者叫协议）。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定。这里的行为约定包括：函数声明要实现的功能；对输入、输出、异常的约定；甚至包括注释中所罗列的任何特殊说明。

• ISP 接口隔离原则

  客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。

• DIP 依赖倒置原则

  高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions）。

• DRY 原则、KISS 原则、YAGNI 原则、LOD 法则

  • DRY

    不要写重复的代码。

  • KISS

    尽量保持简单

  • YAGNI

    不要去设计当前用不到的功能；不要去编写当前用不到的代码。核心思想就是：不要做过度设计。

  • LOD

    不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。

本文原创，才疏学浅，如有纰漏，欢迎指正。尊贵的朋友，如果本文对您有所帮助，欢迎点赞，并期待您的反馈，以便于不断优化。

https://www.emanjusaka.top/2023/08/design-patterns-code-standard-principle

微信公众号：emanjusaka 的编程栈