【设计模式】02-评判代码质量的标准?如何写出高质量代码?

  想写出高质量的代码,我们要明确两个问题:

    • 如何评价代码质量的高低怎么才能写出高质量代码?
      • 从哪些维度评判?
      • 做到什么程度才算高质量?
    • 怎么才能写出高质量代码?

一、如何评价代码质量的高低

  在日常工作中,我们能经常能听到“这段代码写得好”、“这段代码写得烂”。这种描述过于笼统,也不符合我们程序员对于量化的追求。如果查查资料,我们会发现有一系列的形容词可以用来描述代码质量:

    • 灵活性(flexibility)
    • 可扩展性(extensibility)
    • 可维护性(maintainability)
    • 可读性(readability)
    • 可理解性(understandability)
    • 易修改性(changeability)
    • 可复用(reusability)
    • 可测试性(testability)
    • 模块化(modularity)
    • 高内聚低耦合(high cohesion loose coupling)
    • 高效(high effciency)
    • 高性能(high performance)
    • 安全性(security)
    • 兼容性(compatibility)
    • 易用性(usability)
    • 整洁(clean)
    • 清晰(clarity)
    • 简单(simple)
    • 直接(straightforward)
    • 少即是多(less code is more)
    • 文档详尽(well-documented)
    • 分层清晰(well-layered)
    • 正确性(correctness、bug free)
    • 健壮性(robustness)
    • 鲁棒性(robustness)
    • 可用性(reliability)
    • 可伸缩性(scalability)
    • 稳定性(stability)
    • 优雅(elegant)
    • 好(good)
    • 坏(bad)

  这一长串形容词列出来,实在让人头大——我们到底该用哪些词来描述代码质量?

  实际上,这些词都是从不同维度出发来评价代码质量的,而且上面列出的评价维度并非完全独立,有些是相互影响甚至存在包含关系的。我们也很难用其中的某几个词汇来全面评价代码质量——代码质量是综合各种因素得到的结论。

  经过以上解释,我们得出一个略微令人沮丧的事实——并没有一个客观的标准能量化代码质量的高低,评价代码质量是带有很强主观性的过程。因此,经验越深的工程师,给出的评价往往越准确。此外,如果没有其他人的指导,自己闷头写再多代码,也未必能在这方面获得明显提升。

二、最常用的评价标准

  尽管上文讲到,评价代码质量是很主观的过程,但既然我们想搞清楚这个问题,还是要尽量给出相对客观的评判维度。对上文列出的形容词进行筛选,得到以下几个主要方面。

1. 可维护性(maintainability)

  编码开发所说的“维护”无非就是修改 bug、修改老的代码、添加新的代码。

  所谓“可维护性”,就是在不破坏原有代码设计、不引入新的 bug 的前提下,能够快速地修改或添加代码。

  所谓“代码不易维护”,就是修改或添加代码有很大引入新 bug 的风险,且需要花费很长时间才能完成。

  可维护性也是一个很难量化、偏向整体评价的标准,是由很多因素协同作用的结果。代码的可读性好、简洁、可扩展性好,就易于维护。代码分层清晰、模块化好、高内聚低耦合、遵从基于接口而非实现编程的设计原则,也就易于维护。此外,代码的可维护性还和项目代码量、业务复杂程度、所用技术复杂程度、文档是否全面、团队成员水平等因素有关。

  通常来说,如果 bug 容易修复,能够轻松修改、添加功能,我们就主观地认为代码对我们来说易于维护。

2. 可读性(readability)

  代码的可读性是评价代码质量最重要的指标之一,我们在编写代码时应时刻考虑代码是否易于阅读和理解。

  代码的可读性会影响代码的可维护性。无论是修改 bug,还是修改、添加功能,都要先读懂代码。

  评价代码的可读性,需要看以下几点:

    • 代码是否符合编码规范;
    • 是否见名知意;
    • 注释是否详尽;
    • 函数长短是否合适;
    • 模块划分是否清晰;
    • 是否符合高内聚低耦合。

  此外,code review 是一个很好的测验代码可读性的手段。如果其他人可以轻松读懂我们写的代码,说明这段代码可读性较好。反之,说明代码可读性有待提高。

3. 可扩展性(extensibility)

  可扩展性表示代码应对需求变化的能力,我们在不修改或者少量修改原有代码的情况下,通过扩展的方式添加新的功能代码。简而言之,代码预留了一些功能扩展点,可以将新功能代码直接插到扩展点上,不用为了添加一个功能大量改动代码。

  代码是否易于扩展,在一定程度上也决定了代码是否易维护。

4. 灵活性(flexibility)

  灵活性是比较抽象的概念。我们可以从以下几个场景出发来理解灵活性:

    • 代码预留了扩展点,添加新功能时不用修改原有代码,在扩展点上添加新代码即可。
    • 代码已经抽象出很多可以复用的模块、类等代码,添加新功能时可以拿来直接使用。
    • 接口可以应对各种使用场景,满足各种不同的需求。

5. 简洁性(simplicity)

  KISS 原则:Keep It Simple, Stupid。尽量用最简单的方法解决最复杂的问题。代码简单,逻辑清晰。

6. 可复用性(reusability)

  尽量减少重复代码的编写,复用已有代码。DRY 原则:Don't Repeat Yourself.

7. 可测试性(testability)

  可测试性是较少被提及,但非常重要的代码质量评价标准。如果代码可测试性差,比较难写单元测试,基本就可以认为代码设计有问题。

三、如何写出高质量代码

  在以上七个维度的基础上,掌握更加细化、易于落地的编程方法论,譬如面向对象设计思想、设计原则、设计模式、编码规范、重构技巧等。后续的系列博客将详细分析。

原文地址:https://www.cnblogs.com/murongmochen/p/13836199.html