登入帳戶　 |　訂單查詢　 |　購物車/收銀台(0)　|　在線留言板　 |　付款方式　 |　聯絡我們　 |　運費計算　 |　幫助中心　|　 加入書簽
	全部範圍 - 圖書 - 　- 中文簡體書(大陸書) - 　- 英文書（原版） - - 音碟 - 　- 音樂 - 　- 影視 - - 雜誌 - 全文 精確	會員登入   新用戶註冊

HOME新書上架暢銷書架好書推介特價區會員書架精選月讀2023年度TOP分類閱讀雜誌

香港／國際用戶

最新/最熱/最齊全的簡體書網

品種：超過100萬種書，正品正价，放心網購，悭钱省心

送貨：速遞 / 物流，時效：出貨後2-4日

新書推薦： 《 敦煌写本文献学（增订本） 》 售價：NT$ 1010.0 《 耕读史 》 售價：NT$ 500.0 《 地理计算与R语言 》 售價：NT$ 551.0 《 沈括的知识世界：一种闻见主义的实践（中华学术译丛） 》 售價：NT$ 398.0 《 大思维：哥伦比亚商学院六步创新思维模型 》 售價：NT$ 332.0 《 宏观经济学（第三版）【2024诺贝尔经济学奖获奖者作品】 》 售價：NT$ 709.0 《 UE5虚幻引擎必修课（视频教学版） 》 售價：NT$ 505.0 《 真需求 》 售價：NT$ 505.0

建議一齊購買： + NT$ 523 《 程序员修炼之道：从小工到专家 》 + NT$ 531 《 软件驱魔：调试和优化遗留代码的艺术（遗留代码调试和优化领域经典之作，系统讲解有效的调试技术和实用的优化策略） 》 + NT$ 333 《 实现模式（修订版） 》 + NT$ 466 《 程序员的职业素养（世界级软件开发大师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.tw
Copyright (C) 2013 - 2024 （香港）大書城有限公司　All Rights Reserved.