修改软件的艺术 构建易维护代码的9条最佳实践 pdf epub mobi txt 电子书 下载 2025

简体网页||繁体网页

☆☆☆☆☆

[美] 戴维，斯科特，伯恩斯坦（David，Scott，Bernstein） 著，李满庆 译

图书标签:

• 软件工程
• 代码质量
• 可维护性
• 重构
• 最佳实践
• 软件设计
• 编程技巧
• 代码规范
• 软件开发
• 技术书籍

出版社： 人民邮电出版社

ISBN：9787115467768

版次：1

商品编码：12251466

包装：平装

丛书名： 图灵程序设计丛书

开本：16开

出版时间：2017-10-01

用纸：胶版纸

页数：175

正文语种：中文

编辑推荐

遗留代码是指因为种种原因格外难以修正、改进以及使用的代码，这样的代码有很多，每天我们都会因为遗留代码而损失时间、金钱和机遇，软件产业通常轻视可维护性，所以到最后企业花在维护代码上的成本比一开始编写代码的成本还高。本书针对这一现状，总结了9条构建易维护代码、解决遗留代码的zui佳原则，是敏捷开发的具体实战指南。
本书不仅仅是关于如何构建更好的软件，更是关于如何构建更好的软件产业。书中囊括了作者身为专业开发者三十年所学的精华。如果你想要优化软件交付流程，但是感觉到裹足不前、无能为力，那么这本书正适合你。

内容简介

《修改软件的艺术 构建易维护代码的9条*佳实践》会帮你降低构建与维护软件的成本。如果你是软件开发者，将学到一套实践方法以构建易修改的代码，因为在应用当中代码经常需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引入这9个基本的实践方法，会使你的团队更加有效地交付软件而不至于让软件演变成遗留代码。

作者简介

David Scott Bernstein 敏捷教练，曾为IBM、微软、Yahoo等企业提供敏捷实践指导。他的公司To Be Agile （tobeagile.com）指导团队进行测试先行、结对编程以及重构等极限编程实践。

目录

第一部分 遗留代码危机
第 1 章 有些事情不对劲 2
1．1 什么是遗留代码 3
1．2 顺流直下 4
1．3 孤注一掷 6
1．4 为什么瀑布模型不管用 7
1．4．1 食谱与配方 7
1．4．2 开发和测试分离 8
1．5 当“流程”变成“体力劳动” 8
1．6 坚如磐石的管理 9
1．7 此处有龙 10
1．8 评估未知 11
1．9 一个充满外行人的产业 12
1．10 回顾 13
第 2 章 逃出混乱 14
2．1 混乱报告 14
2．1．1 成功的 15
2．1．2 遇到困难的 15
2．1．3 失败的（有缺陷的） 15
2．2 驳斥斯坦迪什咨询集团 16
2．3 项目为何会失败 17
2．4 失败的代价 21
2．4．1 这里十几亿，那里十几亿 21
2．4．2 不同的研究，同样的危机 22
2．5 总结 23
第 3 章 聪明人，新想法 25
3．1 走进敏捷 25
3．2 小即是好 26
3．3 实现敏捷 27
3．4 艺术与技能的平衡 28
3．5 敏捷跨越鸿沟 29
3．6 追求技术卓越 30
3．7 总结 31
第二部分 延续软件生命（和价值）的9种实践方法
第 4 章 9个实践 34
4．1 专家知道什么 35
4．2 守-破-离 36
4．3 首要原则 37
4．4 关于原则 38
4．5 关于实践 38
4．6 原则指导实践 39
4．7 未雨绸缪还是随机应变 40
4．8 定义软件中的“好” 40
4．9 为什么是9个实践 42
4．10 总结 43
第 5 章 实践1：在问如何做之前先问做什么、为什么做、给谁做 44
5．1 不要说如何 44
5．2 将“如何”变为“什么” 45
5．3 要有一个产品负责人 46
5．4 故事描述了做什么、为什么做、给谁做 48
5．5 为验收测试设立明确标准 50
5．6 自动化验收标准 50
5．7 让我们付诸实践 51
5．7．1 产品负责人的7个策略 51
5．7．2 编写出更好用户故事的7个策略 52
5．8 总结 53
第6 章 实践2：小批次构建 55
6．1 更小的谎言 56
6．2 学会变通 56
6．3 控制发布节奏 58
6．4 越小越好 59
6．5 分而治之 60
6．6 更短的反馈回路 62
6．7 提高构建速度 63
6．8 对反馈做出响应 64
6．9 建立待办列表 65
6．10 把用户故事拆分为任务 66
6．11 跳出时间盒子思考 66
6．12 范围控制 67
6．13 让我们付诸实践 69
6．13．1 度量软件开发的7个策略 69
6．13．2 分割用户故事的7个策略 70
6．14 总结 71
第7 章 实践3：持续集成 72
7．1 建立项目的心跳 73
7．2 理解完成、完整完成和完美完成的区别 73
7．3 实践持续部署 74
7．4 自动化构建 75
7．5 尽早集成，频繁集成 76
7．6 迈出第一步 76
7．7 付诸实践 77
7．7．1 构建敏捷设施的7个策略 77
7．7．2 消除风险的7个策略 79
7．8 总结 80
第8 章 实践4：协作 81
8．1 极限编程 82
8．2 沟通与协作 83
8．3 结对编程 84
8．3．1 结对的好处 85
8．3．2 如何结对编程 86
8．3．3 和谁结对 87
8．4 伙伴编程 88
8．5 穿刺，群战，围攻 89
8．5．1 穿刺 89
8．5．2 群战 89
8．5．3 围攻 89
8．6 在时间盒子中对未知进行调研 90
8．7 定期代码审查和回顾会议 91
8．8 加强学习和知识分享 92
8．9 诲人不倦且不耻下问 92
8．10 让我们付诸实践 93
8．10．1 结对编程的7个策略 93
8．10．2 高效回顾会议的7个策略 94
8．11 总结 95
第9 章 实践5：编写整洁的代码 97
9．1 高质量的代码是内聚的 98
9．2 高质量的代码是松散耦合的 99
9．3 高质量的代码是封装良好的 100
9．4 高质量的代码是自主的 102
9．5 高质量的代码是没有冗余的 104
9．6 让代码特质指导我们 105
9．7 今天的代码质量提高会为将来带来速度的提升 106
9．8 让我们付诸实践 107
9．8．1 提高代码质量的7个策略 107
9．8．2 编写可维护代码的7个策略 108
9．9 总结 109
第10 章 实践6：测试先行 110
10．1 测试的种类 111
10．1．1 验收测试 = 客户测试 111
10．1．2 单元测试 = 开发者测试 111
10．1．3 其他测试 = 质量保证测试 112
10．2 质量保证 112
10．2．1 测试驱动开发不能取代质量保证 113
10．2．2 单元测试不是万能的 113
10．3 编写优质测试 114
10．3．1 这不是测试 115
10．3．2 以行为作为单元 115
10．4 TDD可以提供迅速的反馈 116
10．5 TDD可以为重构提供支持 116
10．6 编写可测试的代码 117
10．7 TDD也会失败 118
10．8 如何将TDD引入团队 119
10．9 成为测试感染者 119
10．10 让我们付诸实践 120
10．10．1 进行优质验收测试的7个策略 120
10．10．2 进行优秀单元测试的7个策略 121
10．11 总结 122
第11 章 实践7：用测试描述行为 123
11．1 红条、绿条、重构 124
11．2 一个用测试先行来描述行为的实例 125
11．2．1 编写测试 125
11．2．2 存根代码 126
11．2．3 实现行为 127
11．3 引入限制条件 128
11．3．1 编写测试和代码存根 129
11．3．2 实现行为 129
11．4 我们创建了什么 130
11．5 测试就是标准 132
11．6 测试需要完整 133
11．7 让测试独一无二 134
11．8 用测试来覆盖代码 134
11．9 bug是缺失的测试 135
11．10 用模拟对象来测试工作流 135
11．11 建立防护网 136
11．12 让我们付诸实践 136
11．12．1 使用测试作为标准的7个策略 136
11．12．2 修复bug的7个策略 137
11．13 总结 139
第12 章 实践8：最后实现设计 140
12．1 可变性的阻碍 140
12．2 可持续性开发 142
12．3 编码与清理 143
12．4 软件被阅读的次数比编写次数多 143
12．5 意图导向编程 144
12．6 降低圈复杂度 145
12．7 将创建和使用分离 146
12．8 演化式设计 147
12．9 让我们付诸实践 147
12．9．1 进行演化式设计的7个策略 148
12．9．2 清理代码的7个策略 149
12．10 总结 150
第13 章 实践9：重构遗留代码 151
13．1 投资还是借贷 152
13．2 变成“铁公鸡” 153
13．3 当代码需要修改时 153
13．3．1 对已有代码添加测试 154
13．3．2 通过重构糟糕代码来培养良好习惯 154
13．3．3 推迟那些不可避免的 155
13．4 重构技巧 155
13．4．1 图钉测试 155
13．4．2 依赖注入 156
13．4．3 系统扼杀 156
13．4．4 抽象分支 156
13．5 以支持修改为目的重构 157
13．6 以开闭原则为目的重构 157
13．7 以提高可修改性为目的重构 158
13．8 第二次做好 158
13．9 让我们付诸实践 159
13．9．1 助你正确重构代码的7个策略 159
13．9．2 决定何时进行重构的7个策略 161
13．10 总结 162
第14 章 从遗留代码中学习 163
14．1 更好，更快，更廉价 164
14．2 不在不需要的事情上花钱 166
14．3 循规蹈矩 167
14．4 提升整个软件行业 168
14．5 超越敏捷 169
14．6 将理解具象化 170
14．7 成长的勇气 171
参考文献 174

《精炼代码：拥抱可维护性的软件之道》 在数字洪流奔涌不息的今天，软件的生命力不再仅仅取决于其最初的强大功能，更在于它能否随着时间的推移，灵活地适应变化，高效地被理解、修改和扩展。这并非一个抽象的概念，而是关乎每一个项目生死存亡的关键。本书《精炼代码：拥抱可维护性的软件之道》正是应运而生，它深入探讨了构建和维护高质量、长生命周期软件的本质，旨在为开发者提供一套切实可行、经过实践检验的智慧与技艺，让代码从“冰冷的指令”蜕变为“活力的资产”。 我们深知，软件开发并非一蹴而就的静态过程，而是一个持续演进的动态生命体。一个设计精良、易于维护的软件系统，能够极大地降低开发成本，缩短产品迭代周期，提升团队协作效率，最终在激烈的市场竞争中占据优势。反之，那些如同“迷宫”般难以理解、修改时如同“拆弹”般充满风险的代码，不仅会消耗宝贵的开发资源，更可能扼杀项目的生命力，甚至导致整个系统的崩溃。 本书并非空中楼阁的理论堆砌，而是基于对大量成功与失败案例的深刻洞察，提炼出的九条核心最佳实践。这九条实践环环相扣，共同构建了一个坚实的框架，帮助开发者在软件开发的每一个环节，都将“可维护性”置于核心地位。我们不会简单地罗列一些“应该这样做”的建议，而是深入剖析每一条实践背后的逻辑、原理以及在实际开发中遇到的挑战和解决方案。 第一条：清晰至上的原则——代码的易读性是第一生产力 我们始终坚信，代码首先是写给人看的，其次才是给机器执行的。当代码变得清晰可读，它便拥有了生命力。这意味着，开发者需要投入时间去撰写富有表现力的命名，保持一致的代码风格，运用恰当的注释来阐明意图而非实现细节。我们将在这一章中，深入探讨如何通过精炼的命名、合理的代码结构、有效的代码分块等方式，将复杂的逻辑转化为易于理解的语言。我们将分析那些“糟糕的命名”如何像一道道迷雾，阻碍开发者理解代码，以及“清晰的命名”如何像一盏明灯，指引方向。同时，我们也会探讨如何避免过度冗长的函数和类，如何通过提取、组合等技巧，让代码的结构如同清晰的流程图，一目了然。 第二条：模块化的智慧——拆解复杂，拥抱独立 一个庞大而杂乱的系统，往往是导致维护困难的根源。本书将重点阐述模块化设计的强大力量。通过将大型系统拆解成功能内聚、接口清晰的独立模块，我们可以显著降低系统的复杂度。每一模块的修改，都将尽可能地局限于其内部，避免对其他模块产生“涟漪效应”。我们将深入探讨如何识别合适的模块边界，如何设计简洁且定义明确的接口，以及如何利用依赖注入、服务定位等模式，实现模块间的松耦合。你将学习到如何让代码如同乐高积木一般，可以轻松地被替换、升级或重新组合，从而构建出具有强大适应性的系统。 第三条：单一职责的守护——专注的类，高效的维护 “每个类或函数只做一件事，并且把它做好。”这条看似朴素的原则，却是构建可维护代码的基石。当一个类承担了过多的职责，它就变得脆弱且难以理解。修改其中一个功能，很可能就会影响到其他功能。本章将深入剖析单一职责原则（SRP）的重要性，教你如何识别那些“多面手”的类，如何将其职责进行合理的拆分，并赋予每个新类一个清晰、明确的职责。我们将通过具体的案例，展示SRP如何提升代码的可测试性，降低耦合度，以及让代码的修改变得更加局部化和可控。 第四条：高内聚与低耦合的平衡——构建稳定而灵活的系统 内聚与耦合，是衡量软件设计质量的两个核心指标。高内聚意味着模块内部的元素高度相关，协同工作完成一个整体功能；低耦合则意味着模块之间的依赖关系尽可能弱。本书将详细解析如何在这两者之间找到最佳的平衡点。我们将探讨如何通过封装、抽象等手段，提升模块的内聚性；同时，也会深入讲解如何运用设计模式、接口编程等技术，降低模块间的耦合度。你将理解，高内聚低耦合的系统，如同一个精密的机械装置，各部件各司其职，又协同运转，即使某个部件需要调整，也不会影响到整个机器的正常运行。 第五条：面向接口编程——抽象的力量，解耦的艺术 “面向接口编程”是实现低耦合的关键策略之一。本章将带你领略抽象的强大力量。通过定义接口，我们将关注“做什么”，而非“如何做”。这使得具体的实现可以被随意替换，而调用者却无需关心底层的实现细节。我们将深入讲解接口的定义、实现，以及如何利用接口实现多态，构建更加灵活和可扩展的系统。你将学会如何通过抽象，将变化隔离在接口的实现层，从而保护系统的核心逻辑不受影响。 第六条：优雅的错误处理——让异常成为可控的叙事 错误处理是软件开发中常常被忽视但至关重要的一环。粗暴的错误处理不仅会让用户体验大打折扣，更会给维护者带来巨大的困扰。本书将阐述如何构建一种优雅、清晰的错误处理机制。我们将探讨不同类型的错误（如运行时错误、逻辑错误），以及如何选择恰当的错误处理方式（如返回错误码、抛出异常）。我们还会深入讲解异常的捕获、处理和传递，以及如何通过设计良好的错误信息，帮助开发者快速定位问题，避免“捕获一切”的万能陷阱。 第七条：自动化测试的利剑——保障代码质量的坚实后盾 测试是保障代码质量，提升维护信心的最有力武器。本章将深入讲解自动化测试的重要性，以及如何将其融入开发流程。我们将涵盖单元测试、集成测试、端到端测试等不同层级的测试策略，并详细介绍如何编写高质量的测试用例，如何利用测试驱动开发（TDD）等方法，让测试成为设计过程的一部分。你将明白，自动化测试并非开发过程的负担，而是提升开发效率、降低Bug率、增强代码重构信心的关键。 第八条：版本控制的纪律——时间线上的协作与追溯 版本控制系统是现代软件开发的基石。然而，仅仅使用版本控制是不够的，更需要建立一套清晰、规范的版本控制流程。本书将深入探讨如何有效地利用版本控制系统，如Git，来管理代码变更。我们将讲解分支策略（如Git Flow）、代码合并的原则、提交信息的规范化，以及如何利用版本控制的历史记录来追溯问题、理解代码演变。你将学会如何让版本控制成为团队协作的润滑剂，而非冲突的导火索。 第九条：代码审查的智慧——共同打磨，持续改进 代码审查是软件开发中最具实践价值的协作活动之一。它不仅能帮助发现潜在的Bug和设计缺陷，更能促进团队成员间的知识共享和技能提升。本章将聚焦于如何开展有效且富有成效的代码审查。我们将探讨代码审查的目标、流程，以及如何给出建设性的反馈。你将学习到如何从审查者的角度发现问题，如何从被审查者的角度虚心接受意见，以及如何将代码审查转化为一种持续学习和共同成长的机制。 《精炼代码：拥抱可维护性的软件之道》并非一本速成秘籍，它是一次深入的探索，一次关于软件生命力的思考。我们希望通过本书，能够启发开发者从更宏观的视角审视代码，将“可维护性”内化为一种思维模式，一种行为习惯。无论是初出茅庐的新手，还是身经百战的老将，都能从中汲取养分，不断精进自己的技艺，编写出真正能够经受住时间考验、承载无限可能性的软件。让我们一起踏上这场精炼代码、拥抱可维护性的旅程，共同构建更美好、更持久的软件世界。

评分☆☆☆☆☆

我是一名刚刚踏入软件开发行业不久的新手，对于“代码可维护性”这个概念，虽然有所耳闻，但总觉得有些虚无缥缈，不知道从何下手。在学校里，我们学到的更多是算法、数据结构和如何让程序跑起来，至于写出“好”的代码，好像是个需要时间慢慢摸索的境界。我经常在写完代码后，过一段时间自己都看不懂，更别提让其他同学或者老师来指点了，那种挫败感真的挺强的。 这本书的出现，恰恰填补了我在这方面的知识空白。我期待它能用一种非常直观、易懂的方式，将“可维护性”这个概念拆解开来，让我明白为什么它如此重要，以及如何在实际编码过程中一步步地实现它。书中提到的“9条最佳实践”，对我来说就像是九盏指路明灯，希望能帮助我少走弯路，在职业生涯的早期就建立起良好的编码习惯。我特别想知道，这本书会不会讲解一些具体的代码重构技巧，或者如何通过设计模式来提升代码的可读性，以及在遇到复杂问题时，如何分解并保持代码的清晰。

评分☆☆☆☆☆

作为一个有几年开发经验的程序员，我一直在努力提升自己的技术栈，不仅仅是掌握新的语言和框架，更重要的是提升代码的质量和项目的可维护性。我曾参与过一些大型项目，项目启动时大家热情饱满，代码写得也算是清晰，但随着时间的推移，新功能的不断加入，老代码的不断修改，项目就像一个逐渐失控的怪兽，维护起来越来越困难，bug也越来越多。 这本书的题目《修改软件的艺术：构建易维护代码的9条最佳实践》直接点出了我一直以来关心的问题。我特别好奇书中提到的“9条最佳实践”到底是什么，它们是否能提供一套系统性的方法论，帮助我们应对日益增长的代码复杂性。我期望这本书能够深入浅出地讲解如何通过良好的设计原则、清晰的命名规范、有效的代码组织方式以及恰当的测试策略来提高代码的可维护性。我还希望它能提供一些关于如何处理遗留代码、如何进行代码评审、以及如何在团队中推广和实践这些最佳实践的经验。

评分☆☆☆☆☆

我对软件开发的热情一直很高，但随着接触的项目越来越多，我逐渐意识到，写出能跑的代码只是基础，写出易于理解、易于修改、易于扩展的代码，才是真正考验一个程序员功力的所在。我经历过太多项目，初期还算清晰，但随着迭代次数的增加，代码变得越来越难以捉摸，修改一个bug可能引发一系列新的问题，整个团队都陷入了维护的泥沼。 这本书的出现，让我眼前一亮。“修改软件的艺术”这个标题本身就充满了吸引力，它暗示了这不仅仅是一本技术手册，更是一门关于如何优雅地处理软件生命周期中挑战的学问。而“构建易维护代码的9条最佳实践”，更是直接指向了核心问题。我非常期待书中能深入探讨如何通过结构化的方法来提升代码的可维护性，比如如何进行模块化设计，如何实现低耦合高内聚，以及如何在代码中清晰地表达意图。我希望这本书能够提供一些切实可行的技巧和原则，帮助我写出更具生命力的代码，让团队的协作更加顺畅，让项目的维护成本大大降低。

评分☆☆☆☆☆

这本书简直是为我量身定做的！我是一名在软件开发领域摸爬滚打了近十年的老兵，也算是见过不少“屎山”代码，亲手挖过也亲手填过。每次看到那些维护起来像拆炸弹一样的项目，我就开始怀念起那些清晰、优雅、易于理解的代码。这本书的出现，简直就像久旱逢甘霖。书名就直击痛点，“修改软件的艺术”，这本身就是一句诗，道出了多少开发者的心声。而“构建易维护代码的9条最佳实践”，更是让人眼前一亮，仿佛找到了通往光明彼岸的九级台阶。 我尤其期待书中的“最佳实践”部分。在我看来，写出能运行的代码只是第一步，能被其他人（或者几个月后的自己）轻松理解和修改，才是真正衡量代码质量的标准。很多时候，我们花费在理解和修改他人代码上的时间，远远超过了从零开始编写新代码的时间。这本书是否能提供切实可行的方法，比如如何进行更好的代码组织、如何避免过度设计、如何编写更有意义的注释，甚至是如何在团队协作中保持代码的一致性和可维护性，这些都是我非常好奇和期待的。我希望这本书不仅仅停留在理论层面，而是能提供大量的实际案例和代码示例，让我们能够举一反三，真正地将这些实践应用到日常开发中。

评分☆☆☆☆☆

我是一个在软件行业摸爬滚打多年的开发者，见证了无数项目的兴衰。从最初的对编程的热情，到后来对代码质量的深刻反思，我一直在寻找能够提升代码可维护性的有效方法。我见过太多优秀的创意因为糟糕的代码实现而步履维艰，也见过太多团队因为无法有效维护现有代码而错失良机。 《修改软件的艺术：构建易维护代码的9条最佳实践》这个书名，简直就是直击我心中最痛的点。我非常好奇书中的“9条最佳实践”到底包含哪些内容，它们是否能涵盖代码设计的各个方面，从宏观的架构到微观的函数实现。我期待这本书能够提供一套系统性的指导，帮助我理解为什么某些代码写起来容易出问题，以及如何从源头上避免这些问题。我希望书中能有大量的实际案例，让我能够看到如何在不同的场景下应用这些最佳实践，并且能够感受到这些实践所带来的实际好处，比如缩短开发周期，降低维护成本，提升团队协作效率。

评分☆☆☆☆☆

活动超给力活动超给力

评分☆☆☆☆☆

朋友推荐买的，希望读后有所收获

评分☆☆☆☆☆

很不错呀，便宜的呢

评分☆☆☆☆☆

多买书多学习早日迎娶白富美登上人生巅峰

评分☆☆☆☆☆

还没仔细看呢，推荐给别人了，挺好的，赞一个，很好呢

评分☆☆☆☆☆

东西不错，挺好的，除了运输中没有加膜以外，比较薄~~

评分☆☆☆☆☆

给同事买的，他们挺喜欢的。

评分☆☆☆☆☆

以经验为主导的指南，能使遗留软件项目脱胎换骨。它涵盖了重构、质量度量学、工具链和工作流、持续集成、基础设施自动化以及组织文化等内容。在技术层面，读者将学习如何给代码模块化引进依赖注入，如何定量地衡量软件质量，以及如何实现基础设施的自动化。

评分☆☆☆☆☆

一直在京东买，方便实惠放心