emanjusaka —— 彼岸花开可奈何

彼岸花开可奈何

《设计模式》-代码质量评价标准和设计原则

29
2023-08-24

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 的编程栈