登入帳戶　 |　訂單查詢　 |　購物車/收銀台( 0 )　|　在線留言板　 |　付款方式　 |　運費計算　 |　聯絡我們　 |　幫助中心　|　 加入書簽
會員登入 新用戶登記
HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類瀏覽雜誌 臺灣用戶
品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心 服務：香港／台灣／澳門／海外 送貨：速遞／郵局／服務站

新書上架：簡體書 繁體書
暢銷書架：簡體書 繁體書
好書推介：簡體書 繁體書

四月出版：大陸書 台灣書
三月出版：大陸書 台灣書
二月出版：大陸書 台灣書
一月出版：大陸書 台灣書
12月出版：大陸書 台灣書
11月出版：大陸書 台灣書
十月出版：大陸書 台灣書
九月出版：大陸書 台灣書
八月出版：大陸書 台灣書
七月出版：大陸書 台灣書
六月出版：大陸書 台灣書
五月出版：大陸書 台灣書
四月出版：大陸書 台灣書
三月出版：大陸書 台灣書
二月出版：大陸書 台灣書

『簡體書』修改代码的艺术（世界级计算机专家Michael C. Feathers亲笔撰写，软件开发大师Robert C. Martin倾情推荐，修改代码技术的里程碑式著作）

書城自編碼： 2399904
分類：簡體書→大陸圖書→計算機/網絡→软件工程/开发项目管理
作者： [美]Michael C. Feathers 著
國際書號(ISBN)： 9787111466253
出版社： 机械工业出版社
出版日期： 2014-06-11
版次： 1 印次： 1
頁數/字數： 310/
書度/開本： 16开

售價：HK$ 205.4

我要買 件

 

** 我創建的書架 **
未登入.

新書推薦：
中国历代政治得失
《 中国历代政治得失 》
售價：HK$ 47.8
女子运动术（维持肌肉是更高级的抗衰！变瘦的同时有效增肌，成为更好的自己！）
《 女子运动术（维持肌肉是更高级的抗衰！变瘦的同时有效增肌，成为更好的自己！） 》
售價：HK$ 69.6
你有多敏感，就有多珍贵
《 你有多敏感，就有多珍贵 》
售價：HK$ 70.8
独立战争与世界重启：一部新的十八世纪晚期全球史（方尖碑书系）
《 独立战争与世界重启：一部新的十八世纪晚期全球史（方尖碑书系） 》
售價：HK$ 141.6
中国绘画史（第三卷）
《 中国绘画史（第三卷） 》
售價：HK$ 357.6
德兰修女传：在爱中行走（世界名人名传典藏系列）
《 德兰修女传：在爱中行走（世界名人名传典藏系列） 》
售價：HK$ 60.0
抗癌饮食指导
《 抗癌饮食指导 》
售價：HK$ 94.8
编织大花园.7，趣味十足的时尚编织
《 编织大花园.7，趣味十足的时尚编织 》
售價：HK$ 82.8

 
建議一齊購買：

+

HK$ 162.3
《 程序员修炼之道：从小工到专家 》		 +

HK$ 153.4
《 软件驱魔：调试和优化遗留代码的艺术（遗留代码调试和优化领域经典之作，系统讲解有效的调试技术和实用的优化策略） 》		 +

HK$ 103.3
《 实现模式（修订版） 》		 +

HK$ 144.6
《 程序员的职业素养（世界级软件开发大师Robert C. Martin谈职业素养） 》
編輯推薦：
世界级计算机专家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章　修改软件 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章　我需要修改代码，但不知道要编写哪些测试 142　
13.1　鉴定测试 142　
13.2　鉴定类 145　
13.3　定向测试（Targeted Testing） 146　
13.4　编写鉴定测试的启示 150　
第14章　对库的依赖让我快要崩溃了 151　
第15章　应用全是API调用 153　
第16章　对代码理解不够，所以无法修改 160　
16.1　做笔记，画草图 160　
16.2　列表标记 161　
16.2.1　分离职责 162　
16.2.2　理解方法结构 162　
16.2.3　提取方法 162　
16.2.4　理解变更的影响 162　
16.3　临时重构 162　
16.4　删除没有用的代码 163　
第17章　应用没有结构 164　
17.1　讲述系统的故事 165　
17.2　裸CRC 167　
17.3　对话审查（Conversation Scrutiny） 170　
第18章　测试代码挡路了 171　
18.1　类命名规范 171　
18.2　测试位置 172　
第19章　项目并非面向对象，如何才能够安全地修改 174　
19.1　简单的案例 174　
19.2　困难的案例 175　
19.3　增加新行为 178　
19.4　充分利用面向对象 180　
19.5　完全面向对象 183　
第20章　类太大了，我不想让它继续膨胀 186　
20.1　查看职责 188　
20.2　其他技术 199　
20.3　继续前进 199　
20.3.1　策略 199　
20.3.2　战术 200　
20.4　提取类之后 201　
第21章　在各个地方修改的都是同样的代码 202　
第22章　我需要修改一个巨兽方法，但无法为其编写测试 218　
22.1　巨兽的种类 218　
22.1.1　无序方法 218　
22.1.2　缠结的方法 219　
22.2　使用自动重构支持来对付巨兽 221　
22.3　手动重构挑战 224　
22.3.1　引入检测变量 224　
22.3.2　提取你所知道的内容 227　
22.3.3　收集依赖 228　
22.3.4　打破方法对象 229　
22.4　策略 229　
22.4.1　记下方法的概要 230　
22.4.2　找到序列 230　
22.4.3　首先提取到当前类 231　
22.4.4　提取小段代码 231　
22.4.5　准备好重做提取 231　
第23章　如何知道没有造成任何破坏 232　
23.1　超感编辑（Hyperaware Editing） 232　
23.2　单一目标编辑 233　
23.3　保留签名 234　
23.4　依赖于编译器 236　
23.5　结对编程 238　
第24章　我要崩溃了，它不会再有任何改进 239　
第三部分　打破依赖的技术　
第25章　打破依赖的技术 242　
25.1　调整参数 242　
25.2　分解方法对象 245　
25.3　完善定义 251　
25.4　封装全局引用 252　
25.5　暴露静态方法 257　
25.6　提取并重写调用 259　
25.7　提取并重写工厂方法 261　
25.8　提取并重写getter方法 262　
25.9　提取实现器 265　
25.10　提取接口 269　
25.11　引入实例委托器 274　
25.12　引入静态设置器 275　
25.13　链接替换 280　
25.14　参数化构造函数 280　
25.15　参数化方法 284　
25.16　原始化参数（Primitivize Parameter） 285　
25.17　上推特性 287　
25.18　下推依赖 290　
25.19　使用函数指针替换函数 293　
25.20　使用getter方法替换全局引用 295　
25.21　创建子类并重写方法 297　
25.22　替代实例变量 299　
25.23　模板重定义 302　
25.24　文本重定义 305　
附录　重构 307　
术语表 311　
內容試閱：
第一部分　
修 改 机 制　
　
　
　
第1章　
修 改 软 件　
修改代码是件很不错的事情。那可是我们赖以养家糊口的工作。但是，有些修改代码的方式会让我们的生活更悲催，而有些方式则会让我们的生活轻松写意。业界并没有针对这个问题的太多讨论，我们手头最便于参考的是重构方面的文献。我觉得可以将这个讨论再拓宽一些，谈一下如何处理最棘手的代码。在此之前，我们需要深入理解一下修改的机制。　
1.1　修改软件的四大原因　
为简单起见，让我们看一下修改软件的四种主要原因。　
1. 增加特性　
2. 修正缺陷　
3. 改善设计　
4. 优化对资源的利用 　
1.1.1　增加特性和修正缺陷 　
增加特性看起来是最简单的修改类型。软件表现为一种情况，而用户说系统还需要能够完成更多工作，所以要增加特性，就这么简单。　
假设我们正在使用一种基于Web的应用程序，经理告诉我们，她想要把公司的标识从页面的左端移动到右端。我们和她讨论了一下，发现那并非易事。她不但想要移动标识，还想要做出其他修改。她希望下次发布的时候能够完成。这是修正缺陷还是增加新特性呢？这取决于你看问题的角度。从客户的角度来看，她肯定是在让我们修正问题。她可能就是浏览了网站，然后和部门的同事一起开了个会，就决定要改变标识的位置，并要求再加一点儿功能。从开发者的角度来看，这个变更完全可以看做是增加新特性。“如果他们不总是改变主意，我们现在早就完成了。”但是，在某些组织中，移动标识被看做是修正缺陷，尽管团队需要做大量崭新的工作。　
你可能会说这太主观。你认为是修正缺陷，我认为是增加特性，就是那样。但是，很悲催的是，在很多组织中，由于合同和对质量的发言权所限，缺陷的修正和特性的增加需要分别跟踪，区别对待。在人的层面上，我们可以争论到底是增加特性还是修正缺陷，但两者都只是修改代码和其他制品。不幸的是，关于修正缺陷和新增特性的讨论掩盖了在技术上对我们更重要的一些内容：行为的变更。增加新行为和改变旧行为之间有非常大的区别。　
行为对软件来说至关重要。它是用户所依赖的内容。当我们增加行为的时候，用户会很喜欢（前提是他们真的需要），但是如果我们改变或者删除他们所依赖的特性（引入缺陷），他们就会对我们失去信任。　
在上面公司标识的例子中，我们增加行为了吗？是的。在变更之后，系统会在页面的右侧显示标识。我们去掉什么行为了吗？是的，在左侧不再会有标识。　
让我们来看一种更复杂的情况。假设一位客户想要在页面的右侧添加标识，但之前左边也不存在标识。那么我们肯定要增加行为，但是我们会删除某种行为吗？在将要显示标识的位置已经有什么内容了吗？　
我们是在改变行为，增加行为，还是二者兼而有之呢？　
作为程序员，我们可以从实用的角度对二者进行区分。如果我们需要修改代码（HTML之类的也算作代码），我们就是在改变行为；如果我们只是增加代码并调用它，那么我们通常就是在增加行为。让我们看下另一个例子。以下是Java类中的一个方法：　
　
这个类有一个方法，可以让我们增加音轨列表项。让我们增加另一个方法，用来替换音轨列表项。　
　
当我们增加这个方法的时候，我们是为应用程序增加了新的行为，还是改变了它的行为呢？答案是：都不是。增加一个方法并不会改变行为，除非在某处调用了这个方法。　
让我们再来做一次代码变更。让我们为CD播放器在用户界面上放置一个新的按钮，并将它与replaceTrackListing方法绑定。在这个动作中，我们添加了在replaceTrackListing方法中指定的行为，而且还巧妙地改变了行为。用户界面上有了新的按钮，显示会有所不同。用户界面的显示还可能要比之前慢一微秒。看起来，增加行为而不改变它，几乎是不可能的。　

 

 

書城介紹　 |　合作申請　|　索要書目　 |　新手入門　|　聯絡方式　 |　幫助中心　|　找書說明　 |　送貨方式　|　付款方式 香港用户　 |　台灣用户　|　大陸用户　|　海外用户
megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.