具体描述
编辑推荐
适读人群 ：软件编程的学习者及相关从业者。你有没有在修改其他人代码时感到过沮丧？如今，难以维护的代码已经成为了软件开发中一个很的大问题，导致成本高昂的延期和大量缺陷。本书从实践出发，提供了10条易于实现的原则，可以帮助你开发出可维护且灵活的软件，并且这些原则来自对成百上千个现实系统的分析。
* 编写短小的代码单元：限制方法和构造函数的长度
* 编写简单的代码单元：限制每个方法中分支点的数量
* 编写代码一次，而不是到处复制含有缺陷的代码
* 通过将接口参数提取到对象中，保持短小的代码单元接口
* 分离关注点，避免产生体积庞大的类
* 保持架构组件松耦合
* 平衡顶层组件之间的数量和大小
* 保证代码库尽可能小
* 对代码库进行自动化测试
* 编写整洁的代码，避免会反映更深层问题的“代码坏味道”
内容简介
人类到目前为止已经能够度量越来越多的东西，例如时间、长度等，但是在软件开发领域，我们依然很难去评估一个软件系统的质量，以及维护它的难易程度。可维护性越差，意味着开发成本越高、开发速度越慢，以及由于改动带来的缺陷也越多。在现实中，我们经常会面对代码混乱、模块紧耦合的遗留系统，持续攀升的维护难度会*终导致系统不可维护，从而推倒重来。来自软件改进组织（Software Improvement Group）的咨询师们，从大量实践项目中提取出了编写可维护软件的10个*佳原则，不仅可以用来测量软件的质量和可维护性，还可以指导我们如何编写出高质量的代码。本书会一一介绍这些原则，并且提供了翔实的代码示例，能够让读者一步步了解到如何对代码进行重构，从而达到满足原则、提高可维护性。本书中的代码示例都采用Java语言编写，但是背后的原则也适用于使用其他语言的开发人员。希望各位读者在阅读完本书后，能够了解和掌握如何对软件系统的质量进行评估和测量，以及如何在实践中遵循书中的原则，编写出高质量、简洁的代码，开发出松耦合、高可维护性的系统。
作者简介
译者张若飞，有十年以上IT公司从业经历的资深Java软件开发工程师，对Java和大型互联网、分布式系统有较深研究，曾译有《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关于作者 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，我们已经见过了大量由开发人员在各种实际限制条件下编写的源代码，其中包含了各种妥协的处理。因此，我们将自己的基准测试数据分享出来，让读者了解到现实中代码与理想中的差距。
谁应该阅读本书
本书的目标读者是使用 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# 习惯的代码。我们不相信熟练使用某种语言就可以达到高可维护性。相反，本书中的原则在很大程度上都与语言无关，因此也与语言的习惯用法无关。
虽然我们在书中会介绍或解释许多重构模式，但我们并不是想写一本关于这些模式的书。市场上已经存在了很多关于模式的优秀书籍和网站。我们这本书只关注于为何选择这些重构模式，以及它们如何能提高可维护性。因此，这本书只是学习重构模式的一个起点。
下一本书
我们知道，单个开发人员并不
用户评价
刚拿到《代码不朽：编写可维护软件的10大要则（C版）》这本书时，我其实是抱着一种“看看有多少陈词滥调”的心态。毕竟，关于代码质量和可维护性的讨论已经很多年了。然而，这本书的出现，彻底颠覆了我的看法。作者在开篇就旗帜鲜明地指出了当前软件开发中普遍存在的“技术债务”问题，并且深刻剖析了其对项目周期、开发效率和团队士气带来的长期负面影响。他并非简单地强调“写好代码”，而是从更深层次的角度，阐述了“可维护性”作为软件核心质量属性的重要性，以及它如何直接影响到软件的“生命周期”。书中的“10大要则”，每一个都经过了作者精心的打磨，并且都紧密围绕着C的语言特性展开。例如，在讲解“迪米特法则”（最少知道原则）时，他不仅仅是给出了一个简单的定义，而是结合C的命名空间、类之间的引用关系，深入浅出地解释了如何在C项目中构建低耦合的代码结构，避免“失控的依赖链”。他提供的重构建议，很多都是我之前想过但从未系统实践过的。而且，书中对于“高内聚、低耦合”这两个概念的贯穿，让我对如何设计出易于理解、易于扩展、易于测试的C代码有了更加清晰的框架。作者在章节结尾通常会留有一些思考题或者小练习，这对于我巩固所学知识，以及将理论转化为实践，起到了非常关键的作用。
评分我拿到《代码不朽：编写可维护软件的10大要则（C版）》这本书，纯属偶然，但我不得不说，这是我近期最满意的一笔技术书籍投资。作者的写作风格非常独特，他没有选择那种直白的、命令式的口吻，而是像一位经验丰富的资深开发者，在向你娓娓道来他的开发哲学。书中的“10大要则”并非是生搬硬套的理论，而是经过提炼、升华，并且紧密结合C语言特性的实践指南。他花了很多篇幅在讲解“依赖倒置原则”和“里氏替换原则”上，并通过生动的C代码示例，清晰地展示了如何利用接口和抽象类来解耦，以及如何在继承体系中保持代码的健壮性。尤其令我印象深刻的是，书中对于“接口隔离原则”的阐述，作者通过分析在大型C项目中，一个庞大的接口可能带来的维护噩梦，提出了将大接口拆分成更小、更具针对性的接口的方案，并且给出了具体的重构代码示例。这对我之前在项目中遇到的接口臃肿问题，提供了非常有价值的解决方案。另外，书中对于“组合优于继承”的强调，也让我重新审视了许多过去的编码习惯。作者并没有一概而论地说继承不好，而是指出在许多情况下，使用组合（通过依赖注入、委托等方式）可以带来更好的灵活性和可维护性，并且在C中给出了非常实用的实现方式。整本书的逻辑严谨，从宏观的原则到微观的代码实现，都衔接得非常自然，让我能够循序渐进地理解和掌握这些重要的软件工程思想。
评分这本书《代码不朽：编写可维护软件的10大要则（C版）》，我觉得最大的价值在于它的“落地性”。很多讲软件设计的书，虽然道理都懂，但一到实际编码，就不知道如何下笔。但这本书不一样，作者非常务实，他提出的每一个“要则”，都配有非常具体、非常贴合C实际开发的示例代码。他没有讲那些过于抽象的“银弹”，而是教你如何在C中，通过恰当的设计模式、命名约定、错误处理机制，来具体实现“可维护性”。我特别喜欢他关于“开闭原则”的那部分讲解，他详细分析了如何利用C的泛型、委托、以及各种设计模式（比如工厂模式、抽象工厂模式）来构建能够轻松扩展而无需修改现有代码的系统。他还举了一个例子，说明当需求变更时，一个遵循开闭原则的代码模块，只需要添加新的实现类，而不需要去修改原来已经稳定的核心逻辑，这简直是救命稻草。另外，对于“依赖注入”这个现代C开发中非常重要的概念，书中也给出了非常详尽的解释和示例，他强调了依赖注入如何能够极大地提高代码的可测试性和可维护性，并且推荐了一些常用的C IoC容器的使用方法。整本书读下来，感觉像是跟着一位经验丰富的导师在一步步指导你如何写出更优雅、更健壮的C代码，而不是简单地灌输知识。
评分我拿到《代码不朽：编写可维护软件的10大要则（C版）》这本书，是在参加一个内部代码评审会之后。那次会议让我深刻体会到，代码的可维护性真的不是“锦上添花”，而是“雪中送炭”。这本书的作者，从一个非常独特且深刻的视角，剖析了“代码不朽”的理念。他没有仅仅停留在“写出能运行的代码”，而是将目光放到了代码的“生命周期”上。书中的“10大要则”，不是简单的“原则堆砌”，而是经过作者在C开发实践中反复验证、提炼出的核心方法论。我尤其欣赏他对于“SOLID原则”的深度解读，他并没有把它们当作独立的条目来讲解，而是将它们有机地结合起来，通过C的代码片段，展示了如何通过统一的思路，来解决代码的可维护性问题。例如，他在讲解“里氏替换原则”时，就顺带提到了如何利用C的接口来实现更灵活的类型替换，以及如何避免在继承链中引入不必要的复杂性。更让我惊喜的是，书中对于“代码测试”在可维护性中的作用，也给予了非常重要的篇幅。作者强调了单元测试、集成测试等是如何帮助我们验证代码的健壮性，并且在进行代码重构时提供安全保障。这让我意识到，可维护性不仅仅是编写代码时的技巧，更是一种贯穿于整个开发流程的理念。书中的语言风格也很吸引人，既有专业的技术深度，又不失生动和幽默感，读起来一点也不枯燥。
评分这本书的名字就够吸引人了——《代码不朽：编写可维护软件的10大要则（C版）》。我是在一个技术论坛上偶然看到有人推荐，当时正好在为项目中的代码维护问题感到头疼，所以毫不犹豫地买了下来。翻开第一页，就被作者的开篇所吸引。他没有上来就罗列那些枯燥的规则，而是用一种非常贴近实际开发场景的方式，描绘了“代码不朽”所代表的理想状态，以及我们为什么常常会陷入“代码腐烂”的泥潭。他深入浅出地分析了导致代码难以维护的根源，比如缺乏清晰的设计、技术债务的累积、团队沟通不畅等等。这让我感觉，作者并不是一个只会纸上谈兵的学者，而是一个真正经历过无数项目生死考验的实战派。他提出的“10大要则”，并不是那种放之四海而皆准的鸡汤，而是针对C这种面向对象语言的特性，提出的具体、可操作的实践方法。比如，在讲解“单一职责原则”时，他不仅仅是解释了原则本身，更是用C的类和接口，举例说明了如何通过合理的类划分和抽象，让代码更容易理解和修改。书中对于“开闭原则”的阐述也让我茅茅塞顿开，他提供的多种实现策略，包括但不限于使用接口、抽象类、设计模式（如策略模式、装饰者模式），并且详细分析了它们在C中的具体应用，让我对于如何构建更具扩展性的代码有了全新的认识。而且，作者在讲解的过程中，并没有回避C语言的一些“坑”，而是将如何规避这些“坑”融入到了维护性代码的构建中，这对于提升我的C编码能力大有裨益。
评分这书太贵了 内容也一般 不值这个价 凑字 凑字 凑字
评分这书太贵了 内容也一般 不值这个价 凑字 凑字 凑字
评分可以可以可以
评分一般 还真是一些指导性原则 。。。。。
评分书太太太薄了
评分这书太贵了 内容也一般 不值这个价 凑字 凑字 凑字
评分包装严实，很好
评分这书太贵了 内容也一般 不值这个价 凑字 凑字 凑字
评分6666666666666
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.teaonline.club All Rights Reserved. 图书大百科 版权所有