【设计模式】评价代码的几个维度

水深无声 2023-01-14 01:37 181阅读 0赞

实际上，咱们平时嘴中常说的“好”和“烂”，是对代码质量的一种描述。“好”笼统地表示代码质量高，“烂”笼统地表示代码质量低。对于代码质量的描述，除了“好”“烂”这 样比较简单粗暴的描述方式之外，我们也经常会听到很多其他的描述方式。这些描述方法语义更丰富、更专业、更细化。下面这些几乎涵盖我们所能听到的描述代码质量的所有常用词汇。

灵活性（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）、文档详尽（welldocumented）、分层清晰（well-layered）、
    正确性（correctness、bug free）、健 壮性（robustness）、鲁棒性（robustness）、可用性（reliability）、可伸缩性 （scalability）、稳定性（stability）、
    优雅（elegant）、好（good）、坏（bad） ……

> **所有这些评价维度并不是非此即彼，而是不同角度相辅相成**

## 1. 可读性（readability） ##

软件设计大师 Martin Fowler 曾经说过：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”翻 译成中文就是：“任何傻瓜都会编写计算机能理解的代码。好的程序员能够编写人能够理解的代码。”Google 内部甚至专门有个认证就叫作 Readability。只有拿到这个认证的工程师，才有资格在 code review 的时候，批准别人提交代码。可见代码的可读性有多重要， 毕竟，**代码被阅读的次数远远超过被编写和执行的次数。**

代码的可读性应该是评价代码质量重要的指标之一。我们在编写代码的时候，时刻要考虑到代码是否易读、易理解。除此之外，代码的可读性在非常大程度上会影响 代码的可维护性。毕竟，不管是修改 bug，还是修改添加功能代码，我们首先要做的事情 就是读懂代码。代码读不大懂，就很有可能因为考虑不周全，而引入新的 bug。

既然可读性如此重要，那我们又该如何评价一段代码的可读性呢？

**我们需要看代码是否符合编码规范、命名是否达意、注释是否详尽、函数是否长短合适、模 块划分是否清晰、是否符合高内聚低耦合等等**。你应该也能感觉到，从正面上，我们很难给 出一个覆盖所有评价指标的列表。这也是我们无法量化可读性的原因。

实际上，**code review 是一个很好的测验代码可读性的手段**。如果你的同事可以轻松地读 懂你写的代码，那说明你的代码可读性很好；如果同事在读你的代码时，有很多疑问，那就 说明你的代码可读性有待提高了。

## 2. 可维护性（maintainability） ##

落实到编码开发，所谓的“维护”无外乎就是修改 bug、修改老的代码、添加新的代码之类的工作。**所谓“代码易维护”就是指，在不破坏原有代码设计、不引入新的 bug 的情况下，能够快速地修改或者添加代码**。所谓“代码不易维护”就是指，修改或者添加代码需要 冒着极大的引入新 bug 的风险，并且需要花费很长的时间才能完成。

我们知道，对于一个项目来说，维护代码的时间远远大于编写代码的时间。工程师大部分的 时间可能都是花在修修 bug、改改老的功能逻辑、添加一些新的功能逻辑之类的工作上。 所以，代码的可维护性就显得格外重要。

从正面去分析一个代码是否易维护稍微有点难度。不过，我们可以从侧面上给出一个 比较主观但又比较准确的感受。**如果 bug 容易修复，修改、添加功能能够轻松完成，那我们就可以主观地认为代码对我们来说易维护**。相反，如果修改一个 bug，修改、添加一个功能，需要花费很长的时间，那我们就可以主观地认为代码对我们来说不易维护。

你可能会说，这样的评价方式也太主观了吧？没错，是否易维护本来就是针对维护的人来说的。不同水平的人对于同一份代码的维护能力并不是相同的。对于同样一个系统，熟悉它的资深工程师会觉得代码的可维护性还不错，而一些新人因为不熟悉代码，修改 bug、修改添加代码要花费很长的时间，就有可能会觉得代码的可维护性不那么好。这实际上也印证了我们之前的观点：代码质量的评价有很强的主观性。

## 3. 可扩展性（extensibility） ##

可扩展性也是一个评价代码质量非常重要的标准。它表示我们的**代码应对未来需求变化的能力**。跟可读性一样，代码是否易扩展也很大程度上决定代码是否易维护。那到底什么是代码的可扩展性呢？

代码的可扩展性表示，我们在**不修改或少量修改原有代码的情况下，通过扩展的方式添加新的功能代码**。说直白点就是，**代码预留了一些功能扩展点，你可以把新功能代码，直接插到扩展点上**，而不需要因为要添加一个功能而大动干戈，改动大量的原始代码。

## 4. 灵活性（flexibility） ##

当我们添加一个新的功能代码的时候，**原有的代码已经预留好了扩展点**，我们不需要修改原有的代码，只要在扩展点上添加新的代码即可。这个时候，我们除了可以说代码易 扩展，还可以说代码写得好灵活。

当我们要实现一个功能的时候，发现原有代码中，**已经抽象出了很多底层可以复用的模块**、类等代码，我们可以拿来直接使用。这个时候，我们除了可以说代码易复用之外， 还可以说代码写得好灵活。

当我们使用某组接口的时候，如果这组**接口可以应对各种使用场景，满足各种不同的需求**，我们除了可以说接口易用之外，还可以说这个接口设计得好灵活或者代码写得好灵活。

当我们使用某组接口的时候，如果这组接口可以应对各种使用场景，满足各种不同的需 求，我们除了可以说接口易用之外，还可以说这个接口设计得好灵活或者代码写得好灵 活。从刚刚举的场景来看，如果一段代码易扩展、易复用或者易用，我们都可以称这段代码写得 比较灵活。所以，**灵活这个词的含义非常宽泛，很多场景下都可以使用**。

## 5. 简洁性（simplicity） ##

有一条非常著名的设计原则，你一定听过，那就是 KISS 原则：“Keep It Simple， Stupid”。这个原则说的意思就是\*\*，尽量保持代码简单。代码简单、逻辑清晰，也就意味着易读、易维护\*\*。我们在编写代码的时候，往往也会把简单、清晰放到首位。

不过，很多编程经验不足的程序员会觉得，简单的代码没有技术含量，喜欢在项目中引入一些复杂的设计模式，觉得这样才能体现自己的技术水平。实际上，思从深而行从简，真正的高手能云淡风轻地用最简单的方法解决最复杂的问题。这也是一个编程老手跟编程新手的本 质区别之一。

## 6. 可复用性（reusability） ##

代码的可复用性可以简单地理解为，**尽量减少重复代码的编写，复用已有的代码**。

比如，当说面向对象特性的时候，我们谈到继承、多态存在的目的之一，就是为了提高代码的可复用性；当讲到设计原则的时候，我们会讲到单一职责原则也跟代码的可复用性相 关；当讲到重构技巧的时候，我们会讲到解耦、高内聚、模块化等都能提高代码的可复用性。可见，可复用性也是一个非常重要的代码评价标准，是很多设计原则、思想、模式等所 要达到的终效果。

## 7. 可测试性（testability） ##

相对于前面六个评价标准，代码的可测试性是一个相对较少被提及，但又非常重要的代码质 量评价标准。代码可测试性的好坏，能从侧面上非常准确地反应代码质量的好坏。代码的可 测试性差，比较难写单元测试，那基本上就能说明代码设计得有问题。关于代码的可测试 性，我们在重构那一部分，会花两节课的时间来详细讲解。现在，你暂时只需要知道，代码 的可测试性非常重要就可以了。