在作者的工作经历中,每当同事评论项目代码质量的时候,作者听到最多的评论是“代码 写得很烂”或“代码写得很好”。作者认为,用“好”“烂”这样的字眼来描述代码质量是非常 笼统的。当作者询问代码到底“烂”在何处或“好”在哪里时,尽管大部分同事都能简单地罗 列几个“烂”的方面或好的方面,但他们的回答往往都不够全面,知识点零碎, 也无法切中 要害。

当然,也有一些软件工程师对如何评价代码质量有所认识,如认为好代码是易扩展、易读、 简单、易维护的,等等,但他们对于这些评价的理解往往只停留在表面上,对于诸多更加深入 的问题, 如“怎么才算可读性好?什么样的代码才算易扩展、易维护?可读、可扩展与可维护 之间有什么关系?可维护中的‘维护’两字该如何理解?”,等等,他们并没有太清晰的认识。

实际上,对于代码质量的描述,除“好”“烂”这样比较简单、笼统的描述方式以外,还 有很多语义丰富、专业和细化的描述方式,如下所示:

灵活性(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)等。

面到如此多的词汇,我们到底应该使用哪些词汇来描述一段代码的质量呢?

实际上,我们很难通过其中的某个或某几个词汇来全面地评价代码质量,因为这些词汇是 从不同角度描述代码质量的。例如,在评价一个人的时候,我们往往通过多个方面进行综合评 价,如性格、能力等,否则,对一个人的评价可能是片面的。同样,对于代码质量,我们也需 要综合多种因素进行评价,不应该从单一的角度去评价。例如,一段代码的可扩展性很好,但 可读性很差,那么,我们不能片面地认为这段代码的质量高。

注意,不同的评价角度并不是完全独立的,有些之间存在包含关系、重叠关系等,或者可 以互相影响。例如,代码的可读性和可扩展性好,可能意味着代码的可维护性好。而且,各种 评价角度不是“非黑即白”。例如,我们不能简单地将代码评价为可读或不可读。如果用数字 来量化代码的可读性,那么应该是一个连续的区间值,而非 0 、 1 这样的离散值。

不过,我们真的可以客观地量化一段代码的质量吗?答案是否定的。对一段代码质量的评 价,常常带有很强的主观性。例如,对于什么样的代码才算是可读性好,每个人的评判标准都 不一样。

正是因为代码质量评价的主观性,使得这种主观评价的准确度与软件工程师自身的经验有 极大的关系。软件工程师的经验越丰富,给出的评价往往越准确。形成对比的是,资历较浅的 软件工程师常常觉得没有一个可量化的评价标准作为参考,很难准确判断一段代码的质量。如 果无法辨别代码写得好或坏,那么,即使写再多的代码,编码能力也可能没有太大提高。

在仔细阅读前面罗列的代码质量评价标准之后,读者会发现,有些词汇过于笼统、抽象, 而且偏向于对整体的描述,如优雅、好、坏、整洁和清晰等;有些过于注重细节、偏重方法 论,如模块化、高内聚低耦合、文档详尽和分层清晰等;有些可能并不仅仅局限于编码,与架 构设计等也有关系,如可伸缩性、可复用性和稳定性等。

为了读者有重点地进行学习,作者挑选了7 个常用且重要的评价标准来详细讲解,包括可 维护性、可读性、可扩展性、灵活性、简洁性、可复用性和可测试性。

1 可维护性(maintainability)

对于代码开发,“维护”无外乎修改 bug、修改旧的代码和添加新的代码等。“代码易维护” 是指, 在不破坏原有代码设计、不引入新的 bug 的情况下, 能够快速修改或添加代码。“代码 不易维护”是指,修改或添加代码需要冒极大的引入新 bug 的风险,并且需要很长的时间才能 完成。

对于一个项目,维护代码的时间可能远远大于编写代码的时间。软件工程师可能将大部分 时间花在修复 bug、修改旧的功能逻辑和添加新的功能逻辑之类的工作上。因此,代码的可维 护性就显得格外重要。

对于维护、易维护和不易维护这 3 个概念,我们不难理解。不过,对于实际的软件开发,更重要的是需要清楚如何判断代码可维护性的高低。

实际上,可维护性是一个难以量化、偏向对代码整体进行评价的标准,它类似之前提到的 “好”“坏”“优雅”之类的笼统评价。代码的可维护性高低是由很多因素共同作用的结果。代 码简洁、可读性好、可扩展性好,往往就会使得代码易维护。更深入地讲,如果代码分层清 晰、模块化程度高、高内聚低耦合、遵守基于接口而非实现编程的设计原则等,就可能意味着 代码易维护。除此之外,代码的易维护性还与项目的代码量、业务的复杂程度、技术的复杂程 度、文档的全面性和团队成员的开发水平等诸多因素有关。

2 可读性(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 也是 一个很好的测试代码可读性的手段。如果我们的同事可以轻松地读懂我们写的代码,往往能够 说明我们的代码的可读性不差;如果同事在读我们写的代码时,有很多疑问,那么可能在提示 我们,代码的可读性存在问题,需要重点关注。

3 可扩展性(extensibility)

代码的可扩展性是指在不修改或少量修改原有代码的情况下,能够通过扩展方式添加新功 能代码。换句话说,代码的可扩展性是指在编写代码时预留了一些功能扩展点,我们可以把新 功能代码直接插入扩展点,而不会因为添加新的功能代码而改动大量的原始代码。可扩展性也 是评价代码质量的重要标准。代码的可扩展性表示代码应对未来需求变化的能力。与代码的可 读性一样,代码是否易扩展也在很大程度上决定了代码是否易维护。

4 灵活性(flexibility)

灵活性也可以用来描述代码质量。例如, 我们经常会听到这样的描述:“代码写得很灵 活”。那么,我们如何理解这里提到的“灵活”呢?

尽管很多人用“灵活”描述代码质量,但实际上,“灵活”是一个抽象的评价标准,给“灵活”下定义是很难的。不过,我们可以想一下,我们在什么情况下才会说代码写得很灵活呢?

作者罗列了 3 种场景,帮助读者理解什么是代码的灵活性。

1)当我们添加新功能代码时,由于原有代码中已经预留了扩展点,因此,我们不需要修 改原有代码,只需要在扩展点上添加新代码。这个时候,我们除可以说代码易扩展以外,还可 以说代码写得很灵活。

2)当我们要实现一个功能时,如果原有代码中已经抽象出了很多位于底层且可复用的模 块、类等,那么我们可以直接使用。这个时候,我们除可以说代码易复用以外,还可以说代码 写得很灵活。

3)当我们使用某个类时,如果这个类可以应对多种使用场景,满足多种不同需求,那么, 我们除可以说这个类易用以外,还可以说这个类设计得很灵活或代码写得很灵活。

从上述场景来看,如果一段代码易扩展、易复用,或者易用,我们一般可以认为这段代码 写得很灵活。因此,“灵活”的含义宽泛,很多场景都可以使用。

5 简洁性(simplicity)

有一条非常著名的设计原则,大部分读者应该都听过,那就是 KISS 原则:“Keep It Simple ,Stupid”。该原则的意思是“尽量保持代码简单”。代码简单、逻辑清晰往往意味着代 码易读、易维护。在编写代码的时候,我们往往会把“简单、清晰”原则放到首位。

不过,很多编程经验不足的程序员会觉得,简单的代码没有技术含量,喜欢在项目中引入 一些复杂的设计模式,觉得这样才能体现自己的技术水平。实际上,思从深而行从简,真正的 编程高手往往能用简单的方法解决复杂的问题。

除此之外,虽然我们都能认识到,代码要尽量写得简洁,要符合 KISS 原则,但怎样的代 码才算足够简洁?怎样的代码才算符合 KISS 原则呢?实际上,不是每个人都能准确地做出判 断,因此,在第 3 章介绍 KISS 原则的时候,我们会通过具体的代码示例详细说明。

6 可复用性(reusability)

我们可以将代码的可复用性简单地理解为“尽量减少重复代码的编写,复用已有代码”。 在后续章节中,我们会经常提到“可复用性”这一代码评价标准。例如,当介绍面向对象特性 的时候,我们会提到继承、多态存在的目的之一就是提高代码的可复用性;当介绍设计原则的 时候,我们会提到单一职责原则与代码的可复用性相关;当介绍重构技巧的时候,我们会提到 解耦、高内聚和模块化等能够提高代码的可复用性。可见,可复用性是一个重要的代码评价标 准,也是很多设计原则、设计思想和设计模式等所要实现的最终效果。

实际上,代码的可复用性与 DRY(Don’t Repeat Yourself)原则的关系紧密,因此,在第 3 章介绍 DRY 原则的时候,我们还会介绍代码复用相关的更多知识,如提高代码的可复用性的 编程方法等。

7 可测试性(testability

相比上述 6 个代码质量评价标准,代码的可测试性较少被提及,但它同样重要。代码的可 测试性的高低可以从侧面准确地反映代码质量的高低。代码的可测试性低,难以编写单元测试,那么,基本能够说明代码的设计有问题。

以上内容选自《设计模式之美》

什么样的代码是高质量的代码?_可复用性

谷歌前工程师小争哥代码编程实战经验,23种常用的设计模式,追本溯源,展现高质量代码知识,提升程序员的看家本事!

本书结合真实项目案例, 从面向对象编程范式、设计原则、代码规范、重构技巧和设计模式 5 个方面详细 介绍如何编写高质量代码。

第 1 章为概述, 简单介绍了本书涉及的各个模块, 以及各个模块之间的联系;第 2 章介绍面向对象编程范 式;第 3 章介绍设计原则; 第 4 章介绍代码规范; 第 5 章介绍重构技巧; 第 6 章介绍创建型设计模式; 第 7 章 介绍结构型设计模式;第 8 章介绍行为型设计模式。

本书可以作为各类研发工程师的学习、进阶读物,也可以作为高等院校相关专业师生的教学和学习用书, 以及计算机培训学校的教材。