程序员修炼之道：通向务实的最高境界（第2版）
序 XVII
新版前言 XXI
版前言 XV
提示1：关注你的技艺 XVII
如果你不关心怎么做好，为什么还要花时间去开发软件呢？
提示2：思考！思考你的工作 XVII
关掉辅助驾驶，由自己掌控，持续不断地评估所做的工作。
第1章 务实的哲学 1
1 人生是你的 2
提示3：你有权选择 3
查看完整
新版前言 XXI
版前言 XV
提示1：关注你的技艺 XVII
如果你不关心怎么做好，为什么还要花时间去开发软件呢？
提示2：思考！思考你的工作 XVII
关掉辅助驾驶，由自己掌控，持续不断地评估所做的工作。
第1章 务实的哲学 1
1 人生是你的 2
提示3：你有权选择 3
查看完整
Dave Thomas喜欢驾驶单引擎飞机飞行，而之所以能负担这样奢侈的爱好，是因为他擅长于为各种难题寻找优雅的解决方案，提供诸多领域里的咨询服务——航空、银行、金融服务、电信、交通运输及互联网。在于1994年移居美国前，Dave在英国创立了一家通过ISO9001认证的软件公司，为世界各地的客户开发成熟、定制的软件项目。Dave现在是一位独立顾问，居住在德克萨斯州的达拉斯。Andy Hunt是一位热情的木匠和音乐家，但奇怪的是，他另一个顾问的身份，给为人们所推崇。他的工作领域包括电信、银行、金融服务、公共服务，以及一些更奇特的领域，比如医学成像、图形艺术、互联网服务。Andy的专长是把经过验证的技术与先进的技术混合在一起，创建各种新颖的——但也是实用的——解决方案。Andy在北卡罗莱纳州的罗利市拥有自己的顾问公司。两位作者正在协同工作，以ThePragmaticProgrammer公司的名义，把合起来超过四十年的专业经验带给美国各地的客户。译者云风（真…
查看完整
查看完整
《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的*实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。
序 XVII
新版前言 XXI
版前言 XV
提示1：关注你的技艺 XVII
如果你不关心怎么做好，为什么还要花时间去开发软件呢？
提示2：思考！思考你的工作 XVII
关掉辅助驾驶，由自己掌控，持续不断地评估所做的工作。
第1章 务实的哲学 1
1 人生是你的 2
提示3：你有权选择 3
人生是自己的。把握住人生，让它如你所愿。
2 我的源码被猫吃了 3
提示4：提供选择，别找借口 5
提供选择而不是去找理由。不要只说做不到；解释一下都能做些什么。
3 软件的熵 6
提示5：不要放任破窗 7
只要看到不好的设计、错误的决策、糟糕的代码，就赶紧去纠正。
4 石头做的汤和煮熟的青蛙 9
提示6：做推动变革的催化剂 10
你无法强迫人们去改变，但可以展示美好未来，并帮助他们参与创造。
提示7：牢记全景 10
不要过度沉浸于细枝末节，以免察觉不到周围正在发生的事情。
5 够好即可的软件 11
提示8：将质量要求视为需求问题 12
让用户参与对项目真实质量需求的确定。
6 知识组合 14
提示9：对知识组合做定期投资 16
养成学习的习惯。
提示10：批判性地分析你读到和听到的东西 18
不要受供应商、媒体炒作或教条的影响，根据自身和项目的实际情况来
分析信息。
7 交流！ 20
提示11：英语就是另一门编程语言 20
将英语视作一门编程语言。写文档和编程一样要遵循 DRY 原则、ETC、
自动化等。
提示12：说什么和怎么说同样重要 23
如果无法有效交流，任何伟大的想法都是没有意义的。
提示13：把文档嵌进去，而不要栓在表面 24
与代码隔离的文档，很难保持正确并及时更新。
第2章 务实的方法 27
8 优秀设计的精髓 28
提示14：优秀的设计比糟糕的设计更容易变更 28
适合使用者的事物，都已经过良好设计。对代码来说，这意味着必须适应
变化。
9 DRY——邪恶的重复 30
提示15：DRY——不要重复自己 31
系统中的每一条知识，都必须有单一且无歧义的权威陈述。
提示16：让复用变得更容易 39
只要复用方便，人们就会去做。创建一个支持复用的环境。
10 正交性 40
提示17：消除不相关事物之间的影响 41
设计的组件，需要自成一体、独立自主，有单一的清晰定义的意图。
11 可逆性 48
提示18：不设终决定 50
不要把决定刻在石头上，而要将其视为写在沙滩上的东西，时刻准备
应变。
提示19：放弃追逐时尚 50
尼尔·福特说过：“昨日之实践，即明日之反模式。”要基于基本
原则去选择架构，而不应盲从于流行。
12 曳光弹 51
提示20：使用曳光弹找到目标 53
通过不断尝试并看清着弹点，曳光弹可确保你终击中目标。
13 原型与便签 57
提示21：用原型学习 58
制作原型旨在学习经验，其价值不在于过程中产生的代码，而在于
得到的教训。
14 领域语言 60
提示22：靠近问题域编程 61
用问题领域的语言来做设计和编程。
15 估算 67
提示23：通过估算来避免意外 67
开始之前做估算，能提前发现潜在问题。
提示24：根据代码不断迭代进度表 72
利用实施过程中获得的经验来精细化项目的时间尺度。
第3章 基础工具 74
16 纯文本的威力 75
提示25：将知识用纯文本保存 76
纯文本不会过时。它能够让你的工作事半功倍，并能简化调试和测试
工作。
17 Shell游戏 79
提示26：发挥 Shell 命令的威力 80
当图形化界面无法胜任时，使用 Shell。
18 加强编辑能力 82
提示27：游刃有余地使用编辑器 82
既然编辑器是至关重要的工具，不妨了解一下如何用它更快更准确地
实现需求。
19 版本控制 85
提示28：永远使用版本控制 87
版本控制为你的工作创造了一个时间机器，可以用它重返过去。
20 调试 90
提示29：去解决问题，而不是责备 91
Bug 到底来自你的失误还是别人的失误真的不重要——它终究是你的
问题，需要你来修复。
提示30：不要恐慌 91
不管是对银河系搭车客，还是对开发者来说，都应这样。
提示31：修代码前先让代码在测试中失败 93
在你修 Bug 前，先创建一个聚焦于该 Bug 的测试。
提示32：读一下那些该死的出错信息 93
大多数异常都能告诉失败之物与失败之处。如果足够幸运，你甚至能
得到具体的参数值。
提示33：“select”没出问题 97
在操作系统或编译器中发现 Bug 非常罕见，甚至在第三方产品或库中
也是如此。Bug 大多出现在应用程序中。
提示34：不要假设，要证明 97
在真实环境中证实你的假设——要依赖真实的数据及边界条件。
21 文本处理 99
提示35：学习一门文本处理语言 99
既然每天都要花大量的时间与文本打交道，何不让计算机帮你分担一二？
22 工程日记 101
第4章 务实的偏执 103
提示36：你无法写出完美的软件 103
软件不可能是完美的。对于在所难免的错误，要保护代码和用户免受其
影响。
23 契约式设计 104
提示37：通过契约进行设计 107
代码是否不多不少刚好完成它宣称要做的事情，可以使用契约加以校验
和文档化。
24 死掉的程序不会说谎 113
提示38：尽早崩溃 114
彻底死掉的程序通常比有缺陷的程序造成的损害要小。
25 断言式编程 115
提示39：使用断言去预防不可能的事情 115
如果一件事情不可能发生，那么就用断言来确保其的确不会发生。断言
在校验你的假设，要使用断言在不确定的世界中将你的代码保护起来。
26 如何保持资源的平衡 119
提示40：有始有终 119
只要有可能，对资源进行分配的函数或对象就有责任去释放该资源。
提示41：在局部行动 122
将易变的变量维持在一个范围内，打开资源的过程要短暂且明显可见。
27 不要冲出前灯范围 127
提示42：小步前进——由始至终 127
永远小步前进，不断检查反馈，并且在推进前先做调整。
提示43：避免占卜 129
只在你能看到的范围内做计划。
第5章 宁弯不折 130
28 解耦 131
提示44：解耦代码让改变更容易 132
耦合使事物紧紧绑定在一起，以至于很难只改变其中之一。
提示45：只管命令不要询问 133
不要从对象中取出值，在加以变换后再塞回去，让对象自己来完成这些
工作。
提示46：不要链式调用方法 135
当访问某事物时，使用的点号不要超过一个。
提示47：避免全局数据 137
好给每个方法增加一个额外的参数。
提示48：如果全局非常重要，那么将它包装到API 中 137
……但是，仅限于你真的非常希望它是全局的。
29 在现实世界中抛球杂耍 139
30 变换式编程 149
提示49：编程讲的是代码，而程序谈的是数据 151
所有的程序都在变换数据——将输入转换为输出。开始用变换式方法来
设计吧！
提示50：不要囤积状态，传递下去 156
不要把数据保持在函数或模块的内部，拿出来传递下去。
31 继承税 162
提示51：不要付继承税 165
考虑一下能更好满足需求的替代方案，比如接口、委托或mixin。
提示52：尽量用接口来表达多态 167
无需继承引入的耦合，接口就能明确描述多态性。
提示53：用委托提供服务：“有一个”胜过“是一个” 167
不要从服务中继承，应该包含服务。
提示54：利用 mixin 共享功能 169
mixin 不必承担继承税就可以给类添加功能，而与接口结合可以让
多态不再令人痛苦。
32 配置 170
提示55：使用外部配置参数化应用程序 170
如果代码对一些在应用程序发布后还有可能改变的值有所依赖，那么
就在应用外部维护这些值。
第6章 并发 174
33 打破时域耦合 175
提示56：通过分析工作流来提高并发性 176
利用用户工作流中的并发性。
34 共享状态是不正确的状态 179
提示57：共享状态是不正确的状态 180
共享状态会带来无穷的麻烦，而且往往只有重启才能解决。
提示58：随机故障通常是并发问题 186
或许时间和上下文的变化能暴露并发Bug，但并发Bug无法始终保持
一致，也很难重现。
35 角色与进程 187
提示59：用角色实现并发性时不必共享状态 188
使用角色来管理并发状态，可以避免显式的同步。
36 黑板 193
提示60：使用黑板来协调工作流 195
使用黑板来协调不相关的事实和代理人，能同时保持参与者之间的
独立性和孤立性。
第7章 当你编码时 198
37 听从蜥蜴脑 199
提示61：倾听你内心的蜥蜴 201
当编程举步维艰时，其实是潜意识在告诉你有什么地方不对劲。
38 巧合式编程 204
提示62：不要依赖巧合编程 207
只能依赖可靠的事物。注意偶然事件的复杂性，不要混淆快乐的巧合
与有目的的计划。
39 算法速度 210
提示63：评估算法的级别 214
在开始编程前，对这件事情大概会花多长时间要有概念。
提示64：对估算做测试 214
针对算法的数学分析无法说明所有问题，尝试在目标环境中测试一下
执行代码的耗时。
40 重构 216
提示65：尽早重构，经常重构 219
像除草和翻整花园那样，只要有需要就对代码进行重新编写、修订
和架构，以便找到问题的根源并加以修复。
41 为编码测试 220
提示66：测试与找 Bug 无关 221
测试是观察代码的一个视角，可以从中得到针对设计、接口和耦合度的
反馈。
提示67：测试是代码的个用户 222
用测试的反馈来引导工作。
提示68：既非自上而下，也不自下而上，基于端对端构建 225
创建一小块端到端的功能，从中获悉问题之所在。
提示69：为测试做设计 228
写下代码之前先从测试角度思考。
提示70：要对软件做4
^ 收 起
新版前言 XXI
版前言 XV
提示1：关注你的技艺 XVII
如果你不关心怎么做好，为什么还要花时间去开发软件呢？
提示2：思考！思考你的工作 XVII
关掉辅助驾驶，由自己掌控，持续不断地评估所做的工作。
第1章 务实的哲学 1
1 人生是你的 2
提示3：你有权选择 3
人生是自己的。把握住人生，让它如你所愿。
2 我的源码被猫吃了 3
提示4：提供选择，别找借口 5
提供选择而不是去找理由。不要只说做不到；解释一下都能做些什么。
3 软件的熵 6
提示5：不要放任破窗 7
只要看到不好的设计、错误的决策、糟糕的代码，就赶紧去纠正。
4 石头做的汤和煮熟的青蛙 9
提示6：做推动变革的催化剂 10
你无法强迫人们去改变，但可以展示美好未来，并帮助他们参与创造。
提示7：牢记全景 10
不要过度沉浸于细枝末节，以免察觉不到周围正在发生的事情。
5 够好即可的软件 11
提示8：将质量要求视为需求问题 12
让用户参与对项目真实质量需求的确定。
6 知识组合 14
提示9：对知识组合做定期投资 16
养成学习的习惯。
提示10：批判性地分析你读到和听到的东西 18
不要受供应商、媒体炒作或教条的影响，根据自身和项目的实际情况来
分析信息。
7 交流！ 20
提示11：英语就是另一门编程语言 20
将英语视作一门编程语言。写文档和编程一样要遵循 DRY 原则、ETC、
自动化等。
提示12：说什么和怎么说同样重要 23
如果无法有效交流，任何伟大的想法都是没有意义的。
提示13：把文档嵌进去，而不要栓在表面 24
与代码隔离的文档，很难保持正确并及时更新。
第2章 务实的方法 27
8 优秀设计的精髓 28
提示14：优秀的设计比糟糕的设计更容易变更 28
适合使用者的事物，都已经过良好设计。对代码来说，这意味着必须适应
变化。
9 DRY——邪恶的重复 30
提示15：DRY——不要重复自己 31
系统中的每一条知识，都必须有单一且无歧义的权威陈述。
提示16：让复用变得更容易 39
只要复用方便，人们就会去做。创建一个支持复用的环境。
10 正交性 40
提示17：消除不相关事物之间的影响 41
设计的组件，需要自成一体、独立自主，有单一的清晰定义的意图。
11 可逆性 48
提示18：不设终决定 50
不要把决定刻在石头上，而要将其视为写在沙滩上的东西，时刻准备
应变。
提示19：放弃追逐时尚 50
尼尔·福特说过：“昨日之实践，即明日之反模式。”要基于基本
原则去选择架构，而不应盲从于流行。
12 曳光弹 51
提示20：使用曳光弹找到目标 53
通过不断尝试并看清着弹点，曳光弹可确保你终击中目标。
13 原型与便签 57
提示21：用原型学习 58
制作原型旨在学习经验，其价值不在于过程中产生的代码，而在于
得到的教训。
14 领域语言 60
提示22：靠近问题域编程 61
用问题领域的语言来做设计和编程。
15 估算 67
提示23：通过估算来避免意外 67
开始之前做估算，能提前发现潜在问题。
提示24：根据代码不断迭代进度表 72
利用实施过程中获得的经验来精细化项目的时间尺度。
第3章 基础工具 74
16 纯文本的威力 75
提示25：将知识用纯文本保存 76
纯文本不会过时。它能够让你的工作事半功倍，并能简化调试和测试
工作。
17 Shell游戏 79
提示26：发挥 Shell 命令的威力 80
当图形化界面无法胜任时，使用 Shell。
18 加强编辑能力 82
提示27：游刃有余地使用编辑器 82
既然编辑器是至关重要的工具，不妨了解一下如何用它更快更准确地
实现需求。
19 版本控制 85
提示28：永远使用版本控制 87
版本控制为你的工作创造了一个时间机器，可以用它重返过去。
20 调试 90
提示29：去解决问题，而不是责备 91
Bug 到底来自你的失误还是别人的失误真的不重要——它终究是你的
问题，需要你来修复。
提示30：不要恐慌 91
不管是对银河系搭车客，还是对开发者来说，都应这样。
提示31：修代码前先让代码在测试中失败 93
在你修 Bug 前，先创建一个聚焦于该 Bug 的测试。
提示32：读一下那些该死的出错信息 93
大多数异常都能告诉失败之物与失败之处。如果足够幸运，你甚至能
得到具体的参数值。
提示33：“select”没出问题 97
在操作系统或编译器中发现 Bug 非常罕见，甚至在第三方产品或库中
也是如此。Bug 大多出现在应用程序中。
提示34：不要假设，要证明 97
在真实环境中证实你的假设——要依赖真实的数据及边界条件。
21 文本处理 99
提示35：学习一门文本处理语言 99
既然每天都要花大量的时间与文本打交道，何不让计算机帮你分担一二？
22 工程日记 101
第4章 务实的偏执 103
提示36：你无法写出完美的软件 103
软件不可能是完美的。对于在所难免的错误，要保护代码和用户免受其
影响。
23 契约式设计 104
提示37：通过契约进行设计 107
代码是否不多不少刚好完成它宣称要做的事情，可以使用契约加以校验
和文档化。
24 死掉的程序不会说谎 113
提示38：尽早崩溃 114
彻底死掉的程序通常比有缺陷的程序造成的损害要小。
25 断言式编程 115
提示39：使用断言去预防不可能的事情 115
如果一件事情不可能发生，那么就用断言来确保其的确不会发生。断言
在校验你的假设，要使用断言在不确定的世界中将你的代码保护起来。
26 如何保持资源的平衡 119
提示40：有始有终 119
只要有可能，对资源进行分配的函数或对象就有责任去释放该资源。
提示41：在局部行动 122
将易变的变量维持在一个范围内，打开资源的过程要短暂且明显可见。
27 不要冲出前灯范围 127
提示42：小步前进——由始至终 127
永远小步前进，不断检查反馈，并且在推进前先做调整。
提示43：避免占卜 129
只在你能看到的范围内做计划。
第5章 宁弯不折 130
28 解耦 131
提示44：解耦代码让改变更容易 132
耦合使事物紧紧绑定在一起，以至于很难只改变其中之一。
提示45：只管命令不要询问 133
不要从对象中取出值，在加以变换后再塞回去，让对象自己来完成这些
工作。
提示46：不要链式调用方法 135
当访问某事物时，使用的点号不要超过一个。
提示47：避免全局数据 137
好给每个方法增加一个额外的参数。
提示48：如果全局非常重要，那么将它包装到API 中 137
……但是，仅限于你真的非常希望它是全局的。
29 在现实世界中抛球杂耍 139
30 变换式编程 149
提示49：编程讲的是代码，而程序谈的是数据 151
所有的程序都在变换数据——将输入转换为输出。开始用变换式方法来
设计吧！
提示50：不要囤积状态，传递下去 156
不要把数据保持在函数或模块的内部，拿出来传递下去。
31 继承税 162
提示51：不要付继承税 165
考虑一下能更好满足需求的替代方案，比如接口、委托或mixin。
提示52：尽量用接口来表达多态 167
无需继承引入的耦合，接口就能明确描述多态性。
提示53：用委托提供服务：“有一个”胜过“是一个” 167
不要从服务中继承，应该包含服务。
提示54：利用 mixin 共享功能 169
mixin 不必承担继承税就可以给类添加功能，而与接口结合可以让
多态不再令人痛苦。
32 配置 170
提示55：使用外部配置参数化应用程序 170
如果代码对一些在应用程序发布后还有可能改变的值有所依赖，那么
就在应用外部维护这些值。
第6章 并发 174
33 打破时域耦合 175
提示56：通过分析工作流来提高并发性 176
利用用户工作流中的并发性。
34 共享状态是不正确的状态 179
提示57：共享状态是不正确的状态 180
共享状态会带来无穷的麻烦，而且往往只有重启才能解决。
提示58：随机故障通常是并发问题 186
或许时间和上下文的变化能暴露并发Bug，但并发Bug无法始终保持
一致，也很难重现。
35 角色与进程 187
提示59：用角色实现并发性时不必共享状态 188
使用角色来管理并发状态，可以避免显式的同步。
36 黑板 193
提示60：使用黑板来协调工作流 195
使用黑板来协调不相关的事实和代理人，能同时保持参与者之间的
独立性和孤立性。
第7章 当你编码时 198
37 听从蜥蜴脑 199
提示61：倾听你内心的蜥蜴 201
当编程举步维艰时，其实是潜意识在告诉你有什么地方不对劲。
38 巧合式编程 204
提示62：不要依赖巧合编程 207
只能依赖可靠的事物。注意偶然事件的复杂性，不要混淆快乐的巧合
与有目的的计划。
39 算法速度 210
提示63：评估算法的级别 214
在开始编程前，对这件事情大概会花多长时间要有概念。
提示64：对估算做测试 214
针对算法的数学分析无法说明所有问题，尝试在目标环境中测试一下
执行代码的耗时。
40 重构 216
提示65：尽早重构，经常重构 219
像除草和翻整花园那样，只要有需要就对代码进行重新编写、修订
和架构，以便找到问题的根源并加以修复。
41 为编码测试 220
提示66：测试与找 Bug 无关 221
测试是观察代码的一个视角，可以从中得到针对设计、接口和耦合度的
反馈。
提示67：测试是代码的个用户 222
用测试的反馈来引导工作。
提示68：既非自上而下，也不自下而上，基于端对端构建 225
创建一小块端到端的功能，从中获悉问题之所在。
提示69：为测试做设计 228
写下代码之前先从测试角度思考。
提示70：要对软件做4
^ 收 起
Dave Thomas喜欢驾驶单引擎飞机飞行，而之所以能负担这样奢侈的爱好，是因为他擅长于为各种难题寻找优雅的解决方案，提供诸多领域里的咨询服务——航空、银行、金融服务、电信、交通运输及互联网。在于1994年移居美国前，Dave在英国创立了一家通过ISO9001认证的软件公司，为世界各地的客户开发成熟、定制的软件项目。Dave现在是一位独立顾问，居住在德克萨斯州的达拉斯。Andy Hunt是一位热情的木匠和音乐家，但奇怪的是，他另一个顾问的身份，给为人们所推崇。他的工作领域包括电信、银行、金融服务、公共服务，以及一些更奇特的领域，比如医学成像、图形艺术、互联网服务。Andy的专长是把经过验证的技术与先进的技术混合在一起，创建各种新颖的——但也是实用的——解决方案。Andy在北卡罗莱纳州的罗利市拥有自己的顾问公司。两位作者正在协同工作，以ThePragmaticProgrammer公司的名义，把合起来超过四十年的专业经验带给美国各地的客户。译者云风（真名吴云洋），曾任网易杭州研究中心总监，是网易《大话西游》《梦幻西游》等知名游戏的主要开发者；2011 年与前网易 COO 詹钟晖联合创办简悦（EJOY）游戏公司，兼任 CTO，现该公司已被阿里收购；在互联网、游戏界拥有较高技术影响力，常年发表博客文章，并著有《游戏之旅》及《Effective C （评注版）》。
^ 收 起
^ 收 起
《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的*实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。
比价列表价格走势
