具体描述
本书会帮你降低构建与维护软件的成本。如果你是软件开发者，将学到一套实践方法以构建易修改的代码，因为在应用当中代码经常需要修改。对于和软件开发者合作的管理者来说，本书会向你展示为何引入这九个基本的实践方法，会使你的团队更加有效地交付软件而不至于让软件演变成遗留代码。
作者简介
David Scott Bernstein
敏捷教练，曾为IBM、微软、Yahoo等企业提供敏捷实践指导。
目录信息
第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.3.1 情况发生了改变 18
2.3.2 bug泛滥成灾 19
2.3.3 复杂性危机 20
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
· · · · · · (收起)
读后感
用户评价
坦白说，我一开始对这本书的期待并不是特别高。市面上的软件开发书籍很多，但真正能触及本质、让人眼前一亮的并不多。但“修改软件的艺术”这个名字，总有一种莫名的吸引力，让我想去一探究竟。我总觉得，软件开发最容易被忽视，也最考验功力的，就是对已有代码的修改。很多时候，我们匆忙地加上新的功能，或者修复一个bug，却可能埋下更多隐患。这本书会不会提供一种系统性的方法，让我们在修改的时候，能够更有章法，而不是凭感觉“缝缝补补”？我希望能看到书中对“坏味道”代码的识别，以及如何逐步改善这些“坏味道”的策略。同时，我也对书中关于如何权衡修改成本和收益的讨论很感兴趣。毕竟，在实际工作中，我们总要面对时间和资源的限制，如何在“完美”和“可用”之间找到一个平衡点，是一门重要的学问。
这本书的书名很有意思，“修改软件的艺术”。拿到手的时候，我第一反应就是，这肯定不是一本教你如何从零开始写代码的书。更像是对那些已经写好的软件，如何去“雕琢”、“打磨”的指南。我一直觉得，软件开发中最有挑战性的部分，往往不是创造，而是维护和改进。当需求改变，或者出现了意想不到的bug，甚至是为了优化性能，都需要我们深入到已有的代码中去，小心翼翼地进行修改。这本书的名字就准确地捕捉到了这种精髓——修改，并非简单的增删改查，而是一门需要技巧、经验和洞察力的艺术。我期待它能给我一些关于如何安全、高效地进行软件修改的深刻见解，尤其是在处理遗留系统或者复杂项目中，如何避免“牵一发而动全身”的风险。希望它能提供一些实用的方法论，比如如何更好地理解现有代码的逻辑，如何设计出易于维护的修改方案，以及如何在修改后进行有效的测试，确保软件的稳定性和可靠性。
当我看到“修改软件的艺术”这个书名时，我的脑海里立刻闪过无数次在深夜面对一堆难以理解的代码，试图进行修改的场景。那种感觉，既有挑战，又带着一丝绝望。我希望能在这本书里找到一些能够点亮我内心黑暗的“火种”。我渴望它能提供一套行之有效的方法论，指导我如何去理解那些“前人”留下的代码，即使这些代码看起来杂乱无章，难以入手。也许书中会介绍一些分析工具，或者一些思维模式，能够帮助我快速抓住代码的核心逻辑。更重要的是，我希望能学到如何在修改过程中，尽可能地减少对现有功能的影响，甚至能够通过修改来提升软件的整体质量。我期待这本书能够给我带来一种“化腐朽为神奇”的力量，让我不再畏惧那些复杂的代码库。
我买这本书，主要是被它的“艺术”两个字吸引了。很多技术书籍往往专注于“术”，也就是具体的技巧和工具，但“艺术”则意味着更高层次的理解和创造力。我一直相信，好的软件修改，就像好的艺术品一样，需要有清晰的整体观，同时又能兼顾细节的精妙。我希望能在这本书里找到一些关于如何培养这种“艺术感”的启发。或许它会探讨软件设计的原则如何影响修改的便利性，又或者如何通过重构来提升代码的可读性和可维护性，从而让后续的修改变得更加容易。我脑海里常常浮现出那种感觉，当你修改一段代码，不仅解决了问题，还让整个系统的结构变得更清晰，更优雅，这就是一种艺术的体现。这本书能否帮助我达到这样的境界？我对此充满了好奇，也希望它能提供一些理论框架，让我能够更好地理解“为什么”要这样做，而不仅仅是“怎么”做。
说实话，我对“修改软件的艺术”这本书的期待，更像是寻找一本能让我“顿悟”的宝典。软件开发，尤其是大型项目，往往是一个不断演进的过程，修改是绕不开的环节。但我发现，很多时候，我们只是在“修补”，而不是在“优化”或“进化”。这本书的“艺术”二字，让我觉得它可能触及到了修改软件的更高境界。我希望它能深入探讨那些关于代码的“本质”的东西，比如设计模式在修改中的应用，如何通过清晰的架构设计来降低修改的复杂度，以及如何构建健壮的测试体系来支持频繁的修改。我更想看到的是，如何将修改变成一种创造性的过程，而不是一种负担。这本书会不会揭示一些隐藏在“修改”背后的哲学，让我能从更宏观的视角去理解软件的生命周期，以及我们在其中扮演的角色？我很期待，它能给我带来不同于以往的启发。
挺不错的书，介绍了9种构建易维护代码的方法，有不少真知灼见，但深度不够，代码示例也显得比较少，很多地方不带有自己实践是很难体会的。//去年冬天就想读的书，过了大半年，终于花了几天时间看完，因为拖延，我甚至要付给图书馆约8元的超期罚金。2018-07-06@水澜轩，借于浙江图书馆
最近看过的最没劲的书了，就那么几个论点，啰啰嗦嗦的说。 一股子经管鸡汤书的味道。
作者30年的从业经验，在TDD这章用了一个极其简单的Person类来阐述，是没有说服力的。勇气真的是非常非常重要，重要到我认为只要能拥有勇气就能成功的程度。
讲的非常接地气，很多实践可以应用到实际工作中，虽然方法和概念都是常见的，但是经过提炼和融合以后让人有更深的体悟。
絮絮叨叨的。
