代码不朽：编写可维护软件的10大要则（C#版）-图书

推荐0
收藏3
浏览1.1K

代码不朽：编写可维护软件的10大要则（C#版）

张若飞 (作者)　张若飞 (译者)

书　　号：978-7-121-29898-1
出版日期：2016-09-30
页　　数：168
开　　本：16(178*233)
出版状态：上市销售
维护人：张春雨

电子书￥42.00

购买电子书

纸质版￥69.00

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

高质量、简洁、松耦合、高可维护性系统开发秘诀

序言
“上医治未病，中医治欲病，下医治已病。”
——源自《黄帝内经》
软件是当今信息社会的 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，我们已经见过了大量由开发人员在各种实际限制条件下编写的源代码，其中包含了各种妥协的处理。因此，我们将自己的基准测试数据分享出来，让读者了解到现实中代码与理想中的差距。
谁应该阅读本书
本书的目标读者是使用 C# 语言编程的软件开发人员。在这些读者中，本书又针对两个不同的人群各有侧重点。第一种人群是那些接受过计算机科学或软件工程方面专业学习的开发人员（例如，大学主修这两个专业之一的）。对于这样的开发人员，本书可以巩固他们在专业编程课程上所学的基础知识。
第二种是没有接受过计算机科学或软件工程专业学习的软件开发人员。我们认为这些开发人员主要是一些通过自学、或者大学主修完全是其他专业的人员，但是他们后来又从事了软件开发这个行业。我们的经验是，这类人员除了熟悉所用语言的语法和语义之外，很少接受其他的专业培训。这也是我们在编写本书时特别考虑的人群。
为什么选择这 10 条原则？
本书包含了 10 条原则。前 8 条与《SIG/TüViT 认证产品的可维护性评估标准》( 它是 SIG 评估可维护性的理论基础 ) 中的系统属性一一对应。对于 SIG/TüViT 评估标准，我们按照如下原则来选择评估指标：
数量尽可能少
与技术无关
易于测量
可以与实际的企业软件系统进行有意义的比较
因此，我们就选择出了 SIG/TüViT 评估标准中的这 8 个系统属性，而添加另外两条原则 ( 关于整洁代码和自动化测试 )，是考虑到它们是最关键的，并且可以由开发人员直接控制。
计算机科学和软件工程中的研究人员已经定义了非常多的源代码指标。不管你怎么数，几十个指标总是有的。因此我们这里提炼出的 8 个系统属性，显然只是所有可维护性指标中的很小一部分。
但是，我们想说的是，这 8 个 SIG/TüViT 指标是完全适合、并且足够测量可维护性的，因为它们解决了以下几个问题：
依赖于具体技术实现的指标
有些指标（例如，继承深度）与具体使用的技术（例如，只有在面向对象的语言中才存在继承关系）有很大的关系。但是在现实中，面向对象还远没有达到完全统治的地位，因此我们也需要考虑评估大量非面向对象代码（例如用 Cobol、RPG、C 和 Pascal 编写的系统）的可维护性。
与其他指标紧密相关的指标
有些指标与其他指标之间有非常紧密的关系，系统中的决策点总数就是一个例子。实验证明，这个指标与代码量有直接的关系。这意味着一旦你知道系统中代码行的总数（这很容易测量），那么就几乎可以非常准确地预测出决策点的数量。我们没理由去选择那些较难于测量的指标，因为与较容易测量的指标相比，你不得不花费更多的精力来执行测量并统计结果，但是又得不到什么有用的内容和价值。
在实践中没有区别的指标
有些指标从理论角度看很好，但是在软件开发实践中，它在所有系统上的表现都几乎一样。我们没理由将这些指标作为评估标准，因为无法用它们的结果来区分各个系统。
谁不应该阅读本书？
本书使用 C# 语言（本书中的唯一一种语言）来阐述和解释我们的原则。但是我们并不是要教大家如何使用 C#。我们会假设读者至少可以阅读 C# 代码和 C# 标准库的 API，并且尽可能地保证示例代码足够简单，只使用 C# 语言的基本特性。
这也不是一本介绍 C# 习惯用法的书，也不是要告诉大家什么才是符合 C# 习惯的代码。我们不相信熟练使用某种语言就可以达到高可维护性。相反，本书中的原则在很大程度上都与语言无关，因此也与语言的习惯用法无关。
虽然我们在书中会介绍或解释许多重构模式，但我们并不是想写一本关于这些模式的书。市场上已经存在了很多关于模式的优秀书籍和网站。我们这本书只关注于为何选择这些重构模式，以及它们如何能提高可维护性。因此，这本书只是学习重构模式的一个起点。
下一本书
我们知道，单个开发人员并不能控制开发流程的方方面面。使用哪些开发工具、质量控制如何管理、如何搭建部署环境等，这些都是影响软件质量的重要因素，但它们同时也是一个“团队”的责任。因此，这些主题已经超出了本书的范围，我们会在下一本书《构建软件团队》中介绍这方面的最佳实践，以及如何测量它们的结果。
关于 SIG
虽然本书封面只列出了一个作者名字，但是本书的真正作者不止一人。真正的作者是SIG——一个软件管理咨询公司。因此说，这本书提炼了 SIG 所有顾问从 2000 年以来，在测量软件质量和提出建议过程中总结的集体经验和知识。我们运营着唯一一个经过认证的软件分析实验室，可以按照 ISO 25010 国际标准，对软件产品的质量进行标准化的检测。
SIG 提供的服务之一是我们的“软件风险监控”服务。我们的客户通过该服务，定期（通常每周）上传他们的源代码。然后我们的软件实验室会自动对上传源代码进行检测。SIG 顾问会评估所有自动分析出的异常情况，并与客户讨论。在本书编写时，SIG 已经总共分析了 71 亿行代码，每周有将近 7 千多万行代码被上传到 SIG。
SIG 成立于 2000 年。它的历史可以追溯到荷兰国家数学与计算机科学研究院。即使在十五年后的现在，我们仍然保持并重视与软件工程学术界的联系。SIG 顾问会定期在学术期刊上发表文章，并且许多博士论文都是基于对开发和提高 SIG 质量模型的研究。
关于此版本
这是本书的 C# 版本。所有代码示例都用 C# 编写（并且只用 C# 编写），文中经常提到的工具和名词都是在 C# 社区中所广泛使用的。我们假定读者都拥有一定的 C# 编程经验。如前文所述，本书中用 C# 展示的各条原则，实际上是与语言无关的。本书的 C# 版本由O’Reilly 出版社负责出版发行。
相关书籍
我们列举了 10 条实现高可维护性的基本原则。虽然这可能是许多人关于可维护性方面阅读的第一本书籍，但是我们希望它不要成为最后一本。因此我们推荐读者继续阅读以下图书：
《构建软件团队》，SIG 著
这是同一批作者编写的配套书籍。与本书关注于构建可维护软件的开发原则不同，
这本书关注于软件开发流程的最佳实践以及如何使用“目标—问题—指标”的方法
来有效地测量它们。《构建软件团队》一书将于 2016 年出版。
《代码质量》，Diomidis Spinellis 著
这本书也介绍了关于代码质量的原则，但是同《代码整洁之道》一样，它们都处于更高的抽象层次。

关于作者 ......................................................................................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