修改代码的艺术pdf/txt下载_在线阅读全文

编辑推荐

　　***计算机专家Michael C. Feathers的经典之作，软件开发大师Robert C. Martin作序倾情推荐，修改遗留代码的权威指南　
深入剖析修改遗留代码的各种方法和策略，从理解遗留代码、为其编码测试、重构及增加特性等方面给出大量实用建议，是所有程序开发人员必读之作　

内容简介

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

作者简介

　　Michael C. Feathers　*软件开发大师，就职于Object Mentor公司（这是一家*的提供软件领域的指导、技能开发、知识传播和领导力服务的公司）。他是ACM和IEEE成员，也是CppUnit（从JUnit移植到C++上的单元测试框架）和FitCpp（FIT集成测试框架在C++上的实现）的最初作者，曾3次担任OOPSLA会议的CodeFest主席。目前他在世界范围内提供测试驱动开发、重构、面向对象设计、Java、C#、C++以及极限编程方面的培训和指导。　
　　译者简介　
　　侯伯薇　中荷人寿保险有限公司高级系统分析师，InfoQ中文站翻译团队主编，拥有十多年开发经验，目前致力于技术与业务的融合，让开发出来的程序能够真正提高业务人员的工作效率。热衷于通过翻译和演讲的方式与广大程序员分享和交流，曾翻译过多本技术书籍和几百篇技术短文，并在Scrumgathering、QClub、敏捷之旅等活动上做过技术演讲。　
　
　

目　　录

译者序
序
前言
第一部分　修改机制
第1章　修改软件
1.1　修改软件的四大原因
1.1.1　增加特性和修正缺陷
1.1.2　改善设计
1.1.3　优化
1.2　组合在一起
第2章　利用反馈
2.1　什么是单元测试
2.2　高层次测试
2.3　测试覆盖

译者序 
序 
前言 
第一部分　修改机制 
第1章　修改软件 
1.1　修改软件的四大原因 
1.1.1　增加特性和修正缺陷 
1.1.2　改善设计 
1.1.3　优化 
1.2　组合在一起 
第2章　利用反馈 
2.1　什么是单元测试 
2.2　高层次测试 
2.3　测试覆盖 
2.4　遗留代码修改方法 
2.4.1　确定变更点 
2.4.2　找到测试点 
2.4.3　打破依赖关系 
2.4.4　编写测试 
2.4.5　做出修改并重构 
2.5　本书其他部分 
第3章　感知和分离 
3.1　伪协作程序 
3.1.1　伪对象 
3.1.2　伪对象的两面 
3.1.3　伪对象总结 
3.1.4　模拟对象 
第4章　接缝模型 
4.1　大片的文本 
4.2　接缝 
4.3　接缝类型 
4.3.1　预处理接缝 
4.3.2　链接接缝 
4.3.3　对象接缝 
第5章　工具 
5.1　自动化重构工具 
5.2　模拟对象 
5.3　单元测试用具 
5.3.1　JUnit 
5.3.2　CppUnitLite 
5.3.3　NUnit 
5.3.4　其他xUnit框架 
5.4　一般测试用具 
5.4.1　集成测试框架（Framework for Integrated Test，FIT） 
5.4.2　Fitnesse 
第二部分　修改软件 
第6章　时间很紧张，但还需要修改 
6.1　新生方法（Sprout Method） 
6.2　新生类（Sprout Class） 
6.3　包装方法 
6.4　包装类 
6.5　小结 
第7章　永远都无法完成的修改 
7.1　理解 
7.2　延迟时间 
7.3　打破依赖关系 
7.4　构建依赖关系 
7.5　小结 
第8章　如何添加新特性 
8.1　测试驱动开发 
8.1.1　编写失败的测试案例 
8.1.2　对其进行编译 
8.1.3　使其通过 
8.1.4　去除重复的内容 
8.1.5　编写失败的测试案例 
8.1.6　对其进行编译 
8.1.7　使其通过 
8.1.8　去除重复的内容 
8.1.9　编写失败的测试案例 
8.1.10　对其进行编译 
8.1.11　使其通过 
8.1.12　去除重复的内容 
8.2　根据差异编程 
8.3　小结 
第9章　无法把类放到测试用具中 
9.1　恼人的参数 
9.2　具有隐藏依赖的情况 
9.3　构造Blob的情况 
9.4　恼人的全局依赖 
9.5　可怕的Include依赖 
9.6　洋葱皮参数 
9.7　别名参数 
第10章　无法在测试用具中运行方法 
10.1　隐藏方法的情况 
10.2　“有帮助的”语言特性 
10.3　检测不到的副作用 
第11章　我需要修改代码，应该测试哪些方法 
11.1　推断影响 
11.2　正向推理 
11.3　影响传播 
11.4　推理影响的工具 
11.5　从影响分析中学习 
11.6　简化影响草图 
第12章　我需要在一个地方做多处变更，需要为所有涉及的类打破依赖关系吗 
12.1　拦截点 
12.1.1　简单的情况 
12.1.2　更高层次的拦截点 
12.2　使用夹点来判断设计 
12.3　夹点陷阱 
第13章　我需要修改代码，但不知道要编写哪些测试 
13.1　鉴定测试 
13.2　鉴定类 
13.3　定向测试（Targeted Testing） 
13.4　编写鉴定测试的启示 
第14章　对库的依赖让我快要崩溃了 
第15章　应用全是API调用 
第16章　对代码理解不够，所以无法修改 
16.1　做笔记，画草图 
16.2　列表标记 
16.2.1　分离职责 
16.2.2　理解方法结构 
16.2.3　提取方法 
16.2.4　理解变更的影响 
16.3　临时重构 
16.4　删除没有用的代码 
第17章　应用没有结构 
17.1　讲述系统的故事 
17.2　裸CRC 
17.3　对话审查（Conversation Scrutiny） 
第18章　测试代码挡路了 
18.1　类命名规范 
18.2　测试位置 
第19章　项目并非面向对象，如何才能够安全地修改 
19.1　简单的案例 
19.2　困难的案例 
19.3　增加新行为 
19.4　充分利用面向对象 
19.5　完全面向对象 
第20章　类太大了，我不想让它继续膨胀 
20.1　查看职责 
20.2　其他技术 
20.3　继续前进 
20.3.1　策略 
20.3.2　战术 
20.4　提取类之后 
第21章　在各个地方修改的都是同样的代码 
第22章　我需要修改一个巨兽方法，但无法为其编写测试 
22.1　巨兽的种类 
22.1.1　无序方法 
22.1.2　缠结的方法 
22.2　使用自动重构支持来对付巨兽 
22.3　手动重构挑战 
22.3.1　引入检测变量 
22.3.2　提取你所知道的内容 
22.3.3　收集依赖 
22.3.4　打破方法对象 
22.4　策略 
22.4.1　记下方法的概要 
22.4.2　找到序列 
22.4.3　首先提取到当前类 
22.4.4　提取小段代码 
22.4.5　准备好重做提取 
第23章　如何知道没有造成任何破坏 
23.1　超感编辑（Hyperaware Editing） 
23.2　单一目标编辑 
23.3　保留签名 
23.4　依赖于编译器 
23.5　结对编程 
第24章　我要崩溃了，它不会再有任何改进 
第三部分　打破依赖的技术 
第25章　打破依赖的技术 
25.1　调整参数 
25.2　分解方法对象 
25.3　完善定义 
25.4　封装全局引用 
25.5　暴露静态方法 
25.6　提取并重写调用 
25.7　提取并重写工厂方法 
25.8　提取并重写getter方法 
25.9　提取实现器 
25.10　提取接口 
25.11　引入实例委托器 
25.12　引入静态设置器 
25.13　链接替换 
25.14　参数化构造函数 
25.15　参数化方法 
25.16　原始化参数（Primitivize Parameter） 
25.17　上推特性 
25.18　下推依赖 
25.19　使用函数指针替换函数 
25.20　使用getter方法替换全局引用 
25.21　创建子类并重写方法 
25.22　替代实例变量 
25.23　模板重定义 
25.24　文本重定义 
附录　重构 
术语表

显示全部信息

媒体评论

在线试读部分章节

　　第一部分　
　　修改机制
　　第1章　
　　修改软件　
　　修改代码是件很不错的事情。那可是我们赖以养家糊口的工作。但是，有些修改代码的方式会让我们的生活更悲催，而有些方式则会让我们的生活轻松写意。业界并没有针对这个问题的太多讨论，我们手头最便于参考的是重构方面的文献。我觉得可以将这个讨论再拓宽一些，谈一下如何处理最棘手的代码。在此之前，我们需要深入理解一下修改的机制。　
　　1.1　修改软件的四大原因　
　　为简单起见，让我们看一下修改软件的四种主要原因。　
　　1. 增加特性　
　　2. 修正缺陷　
　　3. 改善设计　
　　4. 优化对资源的利用　
　　1.1.1　增加特性和修正缺陷　
　　增加特性看起来是最简单的修改类型。软件表现为一种情况，而用户说系统还需要能够完成更多工作，所以要增加特性，就这么简单。　
　　假设我们正在使用一种基于Web的应用程序，经理告诉我们，她想要把公司的标识从页面的左端移动到右端。我们和她讨论了一下，发现那并非易事。她不但想要移动标识，还想要做出其他修改。她希望下次发布的时候能够完成。这是修正缺陷还是增加新特性呢？这取决于你看问题的角度。从客户的角度来看，她肯定是在让我们修正问题。她可能就是浏览了网站，然后和部门的同事一起开了个会，就决定要改变标识的位置，并要求再加一点儿功能。从开发者的角度来看，这个变更完全可以看做是增加新特性。“如果他们不总是改变主意，我们现在早就完成了。”但是，在某些组织中，移动标识被看做是修正缺陷，尽管团队需要做大量崭新的工作。　

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

显示全部信息

修改代码的艺术下载

修改代码的艺术

发布书评

相关图书推荐