代码不朽：编写可维护软件的10大要则（Java版） 下载 mobi epub pdf 电子书 2024

编辑推荐

你有没有在修改其他人代码时感到过沮丧？如今，难以维护的代码已经成为了软件开发中一个很的大问题，导致成本高昂的延期和大量缺陷。本书从实践出发，提供了10条易于实现的原则，可以帮助你开发出可维护且灵活的软件，并且这些原则来自对成百上千个现实系统的分析。

* 编写短小的代码单元：限制方法和构造函数的长度

* 编写简单的代码单元：限制每个方法中分支点的数量

* 编写代码一次，而不是到处复制含有缺陷的代码

* 通过将接口参数提取到对象中，保持短小的代码单元接口

* 分离关注点，避免产生体积庞大的类

* 保持架构组件松耦合

* 平衡顶层组件之间的数量和大小

* 保证代码库尽可能小

* 对代码库进行自动化测试

* 编写整洁的代码，避免会反映更深层问题的“代码坏味道”

内容简介

人类到目前为止已经能够度量越来越多的东西，例如时间、长度等，但是在软件开发领域，我们依然很难去评估一个软件系统的质量，以及维护它的难易程度。可维护性越差，意味着开发成本越高、开发速度越慢，以及由于改动带来的缺陷也越多。在现实中，我们经常会面对代码混乱、模块紧耦合的遗留系统，持续攀升的维护难度会*终导致系统不可维护，从而推倒重来。来自软件改进组织（Software Improvement Group）的咨询师们，从大量实践项目中提取出了编写可维护软件的10个*佳原则，不仅可以用来测量软件的质量和可维护性，还可以指导我们如何编写出高质量的代码。本书会一一介绍这些原则，并且提供了翔实的代码示例，能够让读者一步步了解到如何对代码进行重构，从而达到满足原则、提高可维护性。本书中的代码示例都采用Java语言编写，但是背后的原则也适用于使用其他语言的开发人员。希望各位读者在阅读完本书后，能够了解和掌握如何对软件系统的质量进行评估和测量，以及如何在实践中遵循书中的原则，编写出高质量、简洁的代码，开发出松耦合、高可维护性的系统。

作者简介

译者张若飞，有十年以上IT公司从业经历的资深Java软件开发工程师，对Groovy和Grails有较深研究，曾译有《Grails**指南》《Java EE 6开发手册?高级篇（第4版）》《写给大忙人看的Java SE 8》等书。 Joost Visser，SIG研究负责人，掌管这家****的认证软件分析实验室。这家实验室根据ISO 25010国际标准，对软件产品质量进行标准化的测量。本书汇集了SIG顾问们从2000年以来在软件质量测量和建议方面的集体智慧和经验。

目录

关于作者 xi

前言 xiii

第 1 章 简介 1

1．1 什么是可维护性？ 1

1．2 为什么可维护性很重要？ 2

1．3 本书的三个基本理论 4

1．4 对可维护性的误解 5

1．5 评价可维护性 6

1．6 可维护性原则的概述 8

第 2 章 编写短小的代码单元 11

2．1 动机 14

2．2 如何使用本原则 15

2．3 常见的反对意见 22

2．4 参考 25

第 3 章 编写简单的代码单元 27

3．1 动机 33

3．2 如何使用本原则 34

3．3 常见的反对意见 39

3．4 参考 40

第 4 章 不写重复代码 43

4．1 动机 47

4．2 如何使用本原则 48

4．3 常见的反对意见 53

4．4 参考 55

第 5 章 保持代码单元的接口简单 57

5．1 动机 59

5．2 如何使用本原则 60

5．3 常见的反对意见 64

5．4 参考 65

第 6 章 分离模块之间的关注点 67

6．1 动机 72

6．2 如何使用本原则 73

6．3 常见的反对意见 78

第 7 章 架构组件松耦合 81

7．1 动机 82

7．2 如何使用本原则 85

7．3 常见的反对意见 87

7．4 参考 89

第 8 章 保持架构组件之间的平衡 91

8．1 动机 92

8．2 如何使用本原则 93

8．3 常见的反对意见 95

8．4 参考 95

第 9 章 保持小规模代码库 99

9．1 动机 99

9．2 如何使用本原则 102

9．3 常见的反对意见 104

第 10 章 自动化开发部署和测试 107

10．1 动机 109

10．2 如何使用本原则 110

10．3 常见的反对意见 119

10．4 参考 120

第 11 章 编写简洁的代码 121

11．1 不留痕迹 121

11．2 如何使用本原则 122

11．3 常见的反对意见 128

第 12 章 后续事宜 131

12．1 将原则变成实践 131

12．2 低层级（代码单元）原则要优先于高层级（组件）原则 131

12．3 对每次提交负责 132

12．4 下一本书会讨论开发流程的最佳实践 132

附录 A SIG 如何来评估可维护性 133

索引 137

前言/序言

序言

“上医治未病，中医治欲病，下医治已病。”

——源自《黄帝内经》

软件是当今信息社会的 DNA。DNA 虽然小到肉眼无法察觉，它却决定着世界的一切。同样，软件虽然无形且深奥莫测，它却主宰着信息的动向。我们生活中对软件的依赖无处不在 ：教育、管理、生产、贸易、旅行、娱乐、社交等。它是如此普遍，以至于我们理所当然地认为 ：软件会一如既往地提供着已有的一切功能，并且会不断发展以满足我们日益增长的需求。

不仅仅中国在依赖着软件，整个世界都在依赖着中国制造的软件。毫无疑问，在不久的将来，中国会成为制造日益精进的软件的核心大国。我和我来自 Software Improvement Group（SIG）的同事们期望通过这本书，将我们在过去十五年中积累的软件分析经验分享出来，以回馈软件工程界。我们荣幸地为全球，包括中国在内的客户们，诊断软件系统的健康程度，并提出改进的意见与建议，以确保软件代码能够经受时间的考验，在一个良好健康的系统环境下扩展。

在过去的十五年中，我们看到了千百万行优美的代码，同时也看到了不计其数的拙劣的代码。我们从中学会了诊断代码并且对症下药。现在，我们把所学到的经验总结成 10条关于构建可维护软件的基本原则回馈给社会。这 10 条基本原则旨在帮助软件开发人员编写出能经受时间考验的代码。尽管软件近几十年才开始存在，中国传统的哲学理念依旧适用。防患于未然永远好过亡羊补牢。从写下第一行代码时，可维护性就应该获得开发人员的重视，并成为贯穿始终的基本理念。

——Joost Visser，阿姆斯特丹，2016 年 6 月

前言

简单出真知。

——歌德 1

在 SIG 经历了长达 15 年有关软件质量的咨询工作后，我们在可维护性方面学习到了不少经验。

首先，在软件开发过程中，对可维护性的忽视是一个确实存在的问题。可维护性低意味着开发人员需要在维护和修复旧代码方面花费更多的时间和精力。相应地，留给软件开发中最有价值的部分——编写新代码的时间就少了。我们的经验和收集到的数据都表明，低于平均值与高于平均值的可维护性相比，在维护源代码方面至少相差两倍的工作量。

我们会在附录 A 中介绍如何来测量可维护性。

第二，很大程度上，可维护性随着一些小问题的不断发生而变得越来越低。因此，提升可维护性的最高效、最有效的方式，就是找出这些小问题。提升可维护性不需要什么魔法或者高科技，一些简单的技能和知识，再加上对它们的遵守和使用环境，就可以让可维护性有一个飞跃的提升。

在 SIG，我们见过已完全无法再维护的系统。在这些系统中，bug 没有被修复，功能没有被修改或扩展，终究都是因为时间太长、风险太大。不幸的是，这种情况在今天的 IT行业中非常普遍，但是本不应如此。这也是为什么我们编写这 10 条原则的原因。我们希望将每一个一线开发人员都应该掌握的知识和技能分享出来，让每个人都能不断写出高可维护性的代码。我们自信，作为软件开发者的你，在阅读并理解这10条原则后，一定能写出高可维护性的代码。然后剩下的，就是创造出让这些技能发挥最大效果的开发环境，包括互相共享的开发实践、适合的工具等。我们将在第二本书《构建软件团队》（BuildingSoftwareTeams）中介绍这些开发环境。

本书的主题 ：构建可维护软件的 10 条原则

后续章节中所介绍的原则与系统的类型无关。这些原则都是关于代码单元（C# 中的方法）大小及参数数量、代码中决策点的数量，以及源代码等方面的讨论。可能许多开发人员都已经对它们广为熟悉，至少在培训中应该或多或少都听说过一些。这些章节还会提供示例代码（大多数以重构的形式），来帮助读者在实际中掌握这些原则。虽然这些原

则都是通过 C# 语言介绍的，但是它们不受所使用的编程语言的限制。这些原则其中的4/5，大概都来自 SIG/TüViT 2 认证产品可维护性评估标准（Evaluation Criteria for Trusted Product Maintainability 3 ），它是一组用于系统化评估源代码可用性的指标集合。

为什么你应该阅读本书

单独来看本书中的每一条原则，可能都已经被开发人员广为熟知。事实上，许多常用的代码分析工具，都会检查其中的一部分原则。例如，Checkstyle（http://checkstyle.sourceforge.net）（用于 Java）、Style-Cop+（http://stylecopplus.codeplex.com）（用于C#）、Pylint（http://www.pylint.org）（用于 Python）、JSHint（http://jshint.com）（用于C#Script）、RuboCop （https://github.com/bbatsov/rubocop） （用于 Ruby），以及 PMD（https://

pmd.github.io）（可用于多种语言，包括 C# 和 Java），这些工具都会检查代码是否符合第 2 章中所介绍的原则。但是，以下 3 个特点是本书区别于其他一些软件开发书籍的地方：

我们根据经验选择了 10 条最重要的原则

代码风格工具和静态代码分析工具可能会让人望而却步。Checkstyle 6.9 包含了近150 个规则，每个都代表着一条原则。虽然它们都有意义，但是对提高可维护性的效果却不相同。我们已经从中选出了 10 条对提升可维护性最有效的原则。下一页中的“为什么选择这十条原则？”中解释了我们是如何来选择这些原则的。

我们会告诉你如何才能符合这 10 条原则

告诉一个开发人员什么应该做、或者什么不应该做是一回事（正如很多工具做的那样），教会他们如何做到是另一回事。在本书中，对于每一条原则，我们都提供了翔实的示例代码，一步一步讲解如何编写符合原则的代码。

我们提供来自于真实系统的统计数据及示例代码

在 SIG，我们已经见过了大量由开发人员在各种实际限制条件下编写的源代码，其中包含了各种妥协的处理。因此，我们将自己的基准测试数据分享出来，让读者了解到现实中代码与理想中的差距。

谁应该阅读本书

本书的目标读者是使用 Java 语言编程的软件开发人员。在这些读者中，本书又针对两个不同的人群各有侧重点。第一种人群是那些接受过计算机科学或软件工程方面专业学习的开发人员（例如，大学主修这两个专业之一的）。对于这样的开发人员，本书可以巩固他们在专业编程课程上所学的基础知识。

第二种是没有接受过计算机科学或软件工程专业学习的软件开发人员。我们认为这些开发人员主要是一些通过自学、或者大学主修完全是其他专业的人员，但是他们后来又从事了软件开发这个行业。我们的经验是，这类人员除了熟悉所用语言的语法和语义之外，很少接受其他的专业培训。这也是我们在编写本书时特别考虑的人群。

为什么选择这 10 条原则？

本书包含了 10 条原则。前 8 条与《SIG/TüViT 认证产品的可维护性评估标准》( 它是 SIG 评估可维护性的理论基础 ) 中的系统属性一一对应。对于 SIG/TüViT 评估标准，我们按照如下原则来选择评估指标 ：

数量尽可能少

与技术无关

易于测量

可以与实际的企业软件系统进行有意义的比较

因此，我们就选择出了 SIG/TüViT 评估标准中的这 8 个系统属性，而添加另外两条原则 ( 关于整洁代码和自动化测试 )，是考虑到它们是最关键的，并且可以由开发人员直接控制。

计算机科学和软件工程中的研究人员已经定义了非常多的源代码指标。不管你怎么数，几十个指标总是有的。因此我们这里提炼出的 8 个系统属性，显然只是所有可维护性指标中的很小一部分。

但是，我们想说的是，这 8 个 SIG/TüViT 指标是完全适合、并且足够测量可维护性的，因为它们解决了以下几个问题 ：

依赖于具体技术实现的指标

有些指标（例如，继承深度）与具体使用的技术（例如，只有在面向对象的语言中才存在继承关系）有很大的关系。但是在现实中，面向对象还远没有达到完全统治的地位，因此我们也需要考虑评估大量非面向对象代码（例如用 Cobol、RPG、C 和 Pascal 编写的系统）的可维护性。

与其他指标紧密相关的指标

有些指标与其他指标之间有非常紧密的关系，系统中的决策点总数就是一个例子。实验证明，这个指标与代码量有直接的关系。这意味着一旦你知道系统中代码行的总数（这很容易测量），那么就几乎可以非常准确地预测出决策点的数量。我们没理由去选择那些较难于测量的指标，因为与较容易测量的指标相比，你不得不花费更多的精力来执行测量并统计结果，但是又得不到什么有用的内容和价值。

在实践中没有区别的指标

有些指标从理论角度看很好，但是在软件开发实践中，它在所有系统上的表现都几乎一样。我们没理由将这些指标作为评估标准，因为无法用它们的结果来区分各个系统。

谁不应该阅读本书？

本书使用 Java 语言（本书中的唯一一种语言）来阐述和解释我们的原则。但是我们并不是要教大家如何使用 Java。我们会假设读者至少可以阅读 Java 代码和 Java 标准库的 API，并且尽可能地保证示例代码足够简单，只使用 Java 语言的基本特性。

这也不是一本介绍 Java 习惯用法的书，也不是要告诉大家什么才是符合 Java 习惯的代码。我们不相信熟练使用某种语言就可以达到高可维护性。相反，本书中的原则在很大程度上都与语言无关，因此也与语言的习惯用法无关。

虽然我们在书中会介绍或解释许多重构模式，但我们并不是想写一本关于这些模式的书。市场上已经存在了很多关于模式的优秀书籍和网站。我们这本书只关注于为何选择这些重构模式，以及它们如何能提高可维护性。因此，这本书只是学习重构模式的一个起点。

下一

如果在大公司，管理者最需要的就是这样的书，以及相应的开发制度。不然项目的代码就一坨坨的飞翔的翔。

这书很薄，估计就8mm吧，贵的要死，不过里面的东西说的挺好的

一百多页，要六十九块，我也是醉了

经典的图书永远不会过时，重温经典。

呃

书非借不能读也！

很薄的一本，已读，操作性也强

非常薄的一本书，内容也很简洁，但是很不错

太薄了，还那么贵屯着慢慢看屯着慢慢看屯着慢慢看