修改代码的艺术

内容简介

理解修改软件的机制：添加特性、修正缺陷、改进设计、优化性能　
把遗留代码放到测试用具之中　
编写测试，防止引入新的问题　
包含Java、C++、C和C#的示例，其中介绍的大多数技术适用于其他任何语言或平台 　
地确定要在哪些地方修改代码　
处理非面向对象的遗留代码　
处理看起来没有任何结构的应用程序

目录

目　　录　
译者序　
序　
前言　
第一部分　修改机制　
第1章　修改软件 2　
1.1　修改软件的四大原因 2　
1.1.1　增加特性和修正缺陷 2　
1.1.2　改善设计 4　
1.1.3　优化 4　
1.2　组合在一起 4　
第2章　利用反馈 7　
2.1　什么是单元测试 9　
2.2　高层次测试 11　
2.3　测试覆盖 11　
2.4　遗留代码修改方法 14　
2.4.1　确定变更点 14　
2.4.2　找到测试点 14　
2.4.3　打破依赖关系 14　
2.4.4　编写测试 15　
2.4.5　做出修改并重构 15　
2.5　本书其他部分 15　
第3章　感知和分离 16　
3.1　伪协作程序 17　
3.1.1　伪对象 17　
3.1.2　伪对象的两面 20　
3.1.3　伪对象总结 20　
3.1.4　模拟对象 21　
第4章　接缝模型 22　
4.1　大片的文本 22　
4.2　接缝 23　
4.3　接缝类型 25　
4.3.1　预处理接缝 26　
4.3.2　链接接缝 28　
4.3.3　对象接缝 31　
第5章　工具 36　
5.1　自动化重构工具 36　
5.2　模拟对象 38　
5.3　单元测试用具 38　
5.3.1　JUnit 39　
5.3.2　CppUnitLite 40　
5.3.3　NUnit 41　
5.3.4　其他xUnit框架 42　
5.4　一般测试用具 42　
5.4.1　集成测试框架（framework for Integrated Test，FIT） 42　
5.4.2　Fitnesse 43　
第二部分　修改软件　
第6章　时间很紧张，但还需要修改 46　
6.1　新生方法（Sprout Method） 48　
6.2　新生类（Sprout Class） 50　
6.3　包装方法 54　
6.4　包装类 57　
6.5　小结 61　
第7章　永远都无法完成的修改 62　
7.1　理解 62　
7.2　延迟时间 63　
7.3　打破依赖关系 63　
7.4　构建依赖关系 64　
7.5　小结 67　
第8章　如何添加新特性 68　
8.1　测试驱动开发 68　
8.1.1　编写失败的测试案例 69　
8.1.2　对其进行编译 69　
8.1.3　使其通过 69　
8.1.4　去除重复的内容 70　
8.1.5　编写失败的测试案例 70　
8.1.6　对其进行编译 70　
8.1.7　使其通过 71　
8.1.8　去除重复的内容 71　
8.1.9　编写失败的测试案例 71　
8.1.10　对其进行编译 71　
8.1.11　使其通过 72　
8.1.12　去除重复的内容 73　
8.2　根据差异编程 74　
8.3　小结 81　
第9章　无法把类放到测试用具中 82　
9.1　恼人的参数 82　
9.2　具有隐藏依赖的情况 88　
9.3　构造Blob的情况 90　
9.4　恼人的全局依赖 92　
9.5　可怕的Include依赖 99　
9.6　洋葱皮参数 102　
9.7　别名参数 104　
第10章　无法在测试用具中运行方法 107　
10.1　隐藏方法的情况 107　
10.2　“有帮助的”语言特性 110　
10.3　检测不到的副作用 112　
第11章　我需要修改代码，应该测试哪些方法 119　
11.1　推断影响 119　
11.2　正向推理 124　
11.3　影响传播 128　
11.4　推理影响的工具 129　
11.5　从影响分析中学习 131　
11.6　简化影响草图 132　
第12章　我需要在一个地方做多处变更，需要为所有涉及的类打破依赖关系吗 134　
12.1　拦截点 135　
12.1.1　简单的情况 135　
12.1.2　更高层次的拦截点 137　
12.2　使用夹点来判断设计 140　
12.3　夹点陷阱 141　
第13章　我需要修改代码，但不知道要编

摘要与插图

第一部分　
修 改 机 制　
　
　
　
第1章　
修 改 软 件　
修改代码是件很不错的事情。那可是我们赖以养家糊口的工作。但是，有些修改代码的方式会让我们的生活更悲催，而有些方式则会让我们的生活轻松写意。业界并没有针对这个问题的太多讨论，我们手头于参考的是重构方面的文献。我觉得可以将这个讨论再拓宽一些，谈一下如何处理手的代码。在此之前，我们需要深入理解一下修改的机制。　
1.1　修改软件的四大原因　
为简单起见，让我们看一下修改软件的四种主要原因。　
1. 增加特性　
2. 修正缺陷　
3. 改善设计　
4. 优化对资源的利用 　
1.1.1　增加特性和修正缺陷 　
增加特性看起来是单的修改类型。软件表现为一种情况，而用户说系统还需要能够完成更多工作，所以要增加特性，就这么简单。　
假设我们正在使用一种基于Web的应用程序，经理告诉我们，她想要把公司的标识从页面的左端移动到右端。我们和她讨论了一下，发现那并非易事。她不但想要移动标识，还想要做出其他修改。她希望下次发布的时候能够完成。这是修正缺陷还是增加新特性呢？这取决于你看问题的角度。从客户的角度来看，她肯定是在让我们修正问题。她可能就是浏览了网站，然后和部门的同事一起开了个会，就决定要改变标识的位置，并要求再加一点儿功能。从开发者的角度来看，这个变更可以看做是增加新特性。“如果他们不总是改变主意，我们现在早就完成了。”但是，在某些组织中，移动标识被看做是修正缺陷，尽管团队需要做大量崭新的工作。　
你可能会说这太主观。你认为是修正缺陷，我认为是增加特性，就是那样。但是，很悲催的是，在很多组织中，由于合同和对质量的发言权所限，缺陷的修正和特性的增加需要分别跟踪，区别对待。在人的层面上，我们可以争论到底是增加特性还是修正缺陷，但两者都只是修改代码和其他制品。不幸的是，关于修正缺陷和新增特性的讨论掩盖了在技术上对我们更重要的一些内容：行为的变更。增加新行为和改变旧行为之间有大的区别。　
行为对软件来说至关重要。它是用户所依赖的内容。当我们增加行为的时候，用户会很喜欢（前提是他们真的需要），但是如果我们改变或者删除他们所依赖的特性（引入缺陷），他们就会对我们失去信任。　
在上面公司标识的例子中，我们增加行为了吗？是的。在变更之后，系统会在页面的右侧显示标识。我们去掉什么行为了吗？是的，在左侧不再会有标识。　
让我们来看一种更复杂的情况。假设一位客户想要在页面的右侧添加标识，但之前左边也不存在标识。那么我们肯定要增加行为，但是我们会删除某种行为吗？在将要显示标识的位置已经有什么内容了吗？　
我们是在改变行为，增加行为，还是二者兼而有之呢？　
作为程序员，我们可以从实用的角度对二者进行区分。如果我们需要修改代码（HTML之类的也算作代码），我们就是在改变行为；如果我们只是增加代码并调用它，那么我们通常就是在增加行为。让我们看下另一个例子。以下是Java类中的一个方法：　
　
这个类有一个方法，可以让我们增加音轨列表项。让我们增加另一个方法，用来替换音轨列表项。　
　
当我们增加这个方法的时候，我们是为应用程序增加了新的行为，还是改变了它的行为呢？答案是：都不是。增加一个方法并不会改变行为，除非在某处调用了这个方法。　
让我们再来做一次代码变更。让我们为CD播放器在用户界面上放置一个新的按钮，并将它与replaceTrackListing方法绑定。在这个动作中，我们添加了在replaceTrackListing方法中指定的行为，而且还巧妙地改变了行为。用户界面上