Bitter Java中文版 (2010 年度畅销榜NO.2217 )

说实在的，很少有计算机的书能把我迷住，Bruce Tate的《Bitter Java》却是个例外，这本书让我不忍释卷，每看完一章后，就等不及地想看下一章。要问我的建议？很简单，如果你没办法放下手边的事情，不能安排出全天的时间来静心地看这本书，那就先别开始看。
——Hays W. “Skip” McCormick III，《AntiPatterns》的合著者
大多数软件项目都遭遇了失败，这是一个公认的事实。要从这些失败中汲取重要的教训，这正是《Bitter Java》的目的。
只是重用设计模式并不一定能保证成功：模式就像某处危险地形的部分地图。这些模式很有帮助，但是不能防止你迷失。本书会教读者怎么发现自己迷路了，以及如何回到正道上来。本书通过代码示例展示了Java编程中常见的陷阱；还提供了重构代码，并解释了为什么新方案是安全的。
本书系统地介绍了常见的服务器端Java编程错误，以及这些错误产生的原因和解决方案。书中涵盖了基本Java和J2EE概念的反模式，如servlet、JSP、EJB、企业连接模型和可扩展性等，通过代码示例展示了Java编程中常见的陷阱，还提供了重构代码，并解释了为什么新方案是安全的。本书适合中级水平的Java程序员、分析员或架构师阅读，通过研究书中介绍的反模式，可以吸取别人的经验教训，在工作中少走弯路。

目 录
第一部分　基 础 知 识
第1章　Bitter传说 2
1.1　自由降落的Java开发 2
1.1.1　生活中的反模式 4
1.2　使用设计模式强调正面 4
1.2.1　设计模式在线资源 5
1.2.2　UML为模式提供了语言 6
1.3　反模式从负面学习 6
1.3.1　一些著名的反模式 6
1.3.2　实际中的反模式 7
1.3.3　反模式资源 8
1.4　反模式的思想并不是全新的 9
1.4.1　从业界学到的教训 9
1.4.2　检测工作 10
1.4.3　重构反模式 11
1.5　为什么写这本书 11
1.5.1　本书方法 12
1.5.2　本书工具 12
1.5.3　本书组织结构 12
1.5.4　本书读者对象 14
1.6　前瞻 14
第2章　状况之苦 15
2.1　反模式滋生的土壤 15
2.1.1　分层的好处 15
2.1.2　分层也会对我们不利 17
2.2　Internet技术 18
2.2.1　Internet拓扑结构会影响我们的应用 18
2.2.2　企业层可以增加安全，也会加大开销 19
2.2.3　标准提供了Internet支持，同时增加了层 21
2.2.4　TCP和IP提供底层通信 21
2.2.5　HTTP提供应用级传输 22
2.2.6　HTML和XML 22
2.2.7　小反模式：Web页面上有太多元素 23
2.3　对象技术和反模式 25
2.3.1　封装有助于隔离修改 25
2.3.2　继承支持共同行为的打包 26
2.3.3　多态支持灵活的重用 26
2.3.4　小反模式：过度分层 27
2.3.5　Java的舞台 28
2.4　Java技术解决反模式 28
2.5　瀑布的主要问题 30
2.5.1　迭代方法 31
2.5.2　小反模式：不完整的过程转换 31
2.5.3　编程新视野：极限编程 32
2.6　状况之苦速览 33
2.7　本章介绍的反模式 33
第二部分　服务器端Java反模式
第3章　servlet之苦 37
3.1　孤注一掷 37
3.1.1　早期的反模式：神奇按钮 37
3.1.2　利用模型-视图-控制器模式构建 38
3.1.3　未能分离模型和视图 39
3.1.4　分出模型 40
3.2　反模式：神奇servlet 41
3.2.1　可以使用servlet作为模型吗 41
3.2.2　落入神奇servlet陷阱 43
3.2.3　导致神奇servlet的原因 46
3.3　解决方案：使用命令重构 47
3.3.1　分出模型 47
3.3.2　用命令对象包装模型 48
3.3.3　分离模型逻辑 48
3.3.4　分离返回视图 52
3.3.5　使用JSP建立返回视图 54
3.4　小结 56
3.5　本章介绍的反模式 56
第4章　JSP之苦 58
4.1　还没有结束 58
4.1.1　找出危险信号 58
4.2　反模式：整块JSP 59
4.2.1　这个程序未能做到模型-视图分离 60
4.2.2　解决方案：重构为模型-视图-控制器 61
4.3　反模式：复合JSP 62
4.3.1　该不该结合多个JSP 63
4.3.2　结合了两个界面的例子 64
4.3.3　解决方案：分解JSP 68
4.3.4　在控制器servlet中做判定 68
4.4　小反模式：过粗和过细的命令 71
4.4.1　一组中有太多的命令 72
4.4.2　解决方案：重构为合适的粒度 72
4.4.3　有关粒度的提示 73
4.5　小反模式：胖命令 74
4.6　反模式回顾 74
4.7　本章介绍的反模式 74
第5章　缓存管理之苦 77
5.1　我们需要缓存！ 77
5.2　反模式：缺少缓存 79
5.2.1　没有缓存的糟糕BBS 79
5.2.2　构建ShowBoard的模型、视图和控制器 80
5.2.3　构建ShowThread的模型、视图和控制器 82
5.2.4　构建AddPost的模型、视图和控制器 86
5.2.5　性能问题 91
5.3　解决方案：缓存 91
5.3.1　解决方案1：使用一个硬件缓存 92
5.3.2　解决方案2：缓存命令 92
5.3.3　为BBS增加缓存 93
5.3.4　对缓存命令的改进 97
5.4　与缓存有关的小反模式 99
5.4.1　对静态缓存的并发访问 99
5.4.2　不断膨胀的缓存 99
5.5　反模式：同步读/写瓶颈 99
5.5.1　读者之间的冲突会降低性能 100
5.5.2　读/写锁允许正确地共享访问 101
5.6　消除无缓存反模式 102
5.7　本章介绍的反模式 103
第6章　内存之苦 105
6.1　了解内存泄漏和反模式 105
6.1.1　管理内存 106
6.1.2　理解垃圾回收 106
6.1.3　引用计数 107
6.1.4　可达对象 108
6.2　C++换Java 109
6.2.1　导致Java内存泄漏的情况 109
6.2.2　找出Java的内存泄漏 109
6.3　反模式：流失监听者泄漏 110
6.3.1　分析一些危险的做法 111
6.3.2　解决方案1：显式地删除监听者 113
6.3.3　解决方案2：缩短锚的生命周期 114
6.3.4　解决方案3：弱化引用 114
6.3.5　引用对象可以简化内存管理 115
6.4　反模式：泄漏集合 115
6.4.1　由于缓存和会话状态导致的问题 116
6.4.2　解决方案1：搜索常见的警告信号 116
6.4.3　解决方案2：让增加/删除调用匹配 117
6.4.4　解决方案3：使用软引用完成缓存 117
6.4.5　解决方案4：使用带弱引用的集合 118
6.4.6　解决方案5：使用finally 118
6.5　解决内存泄漏 118
6.5.1　确信存在泄漏 118
6.5.2　确定泄漏应当得到修正 119
6.5.3　隔离问题 120
6.5.4　确定根源，修正问题 120
6.5.5　防止将来出现同样的问题 121
6.6　小反模式：小肥猪 121
6.6.1　串管理 122
6.6.2　集合 122
6.6.3　继承链 123
6.7　小结 123
6.8　本章介绍的反模式 123
第7章　连接和耦合之苦 125
7.1　建立连接 125
7.2　反模式：连接抖动 125
7.2.1　对每个访问都创建和终止连接 126
7.2.2　解决方案：利用池来重用连接 127
7.2.3　重构BBS例子，增加入池连接 129
7.2.4　使用getPooledConnection 130
7.2.5　使用J2EE连接器体系结构 131
7.3　反模式：分离清洁器 132
7.3.1　异常可能导致分离清洁器 133
7.3.2　解决方案：在finally中让连接与清理配对 134
7.4　反模式：捆绑的连接 135
7.4.1　通信缓冲区 136
7.4.2　过早绑定 138
7.4.3　解决方案1：利用XML消息解耦合 138
7.4.4　解决方案2：利用Web服务延迟绑定 139
7.5　关于XML误用的小反模式 140
7.5.1　XML金榔头 140
7.5.2　XML转换之苦 141
7.6　小反模式：严格XML 142
7.6.1　命名冲突 142
7.6.2　严格构造 144
7.6.3　限制性的可变内容容器 145
7.6.4　XML版本问题 147
7.7　小结：苦连接变甜 148
7.8　本章介绍的反模式 148
第8章　bean之苦 151
8.1　Enterprise JavaBeans简要回顾 151
8.1.1　基于组件的分布式体系结构 152
8.1.2　EJB的类型 152
8.2　利用EJB实现的糟糕BBS 153
8.2.1　EJB应用中的元素 154
8.2.2　构建远程接口 155
8.2.3　创建home接口 156
8.2.4　实现bean类 158
8.2.5　定义主键 162
8.2.6　创建部署描述文件 163
8.2.7　使用模型 165
8.3　反模式：往返通信 165
8.3.1　计算分布式部署的开销 166
8.3.2　会话太多的接口 167
8.3.3　解决方案：利用外观组合往返通信 168
8.3.4　往返通信的根源 169
8.3.5　利用外观重构BBS 169
8.4　反模式：张冠李戴 175
8.4.1　小反模式：bean托管连接 175
8.4.2　解决方案：视图、映射器、bean托管连接 176
8.4.3　小反模式：实体bean只是完成一些轻量级的功能 176
8.4.4　小反模式：实体bean仅用于读 177
8.4.5　小反模式：实体bean仅用于写而不读 177
8.4.6　麻烦的可滚动列表 177
8.4.7　总解决方案：选择合适的bean完成合适的任务 178
8.5　小反模式：一切都是EJB 178
8.6　EJB和缓存 179
8.6.1　利用外观实现缓存 179
8.7　消除苦bean 180
8.8　本章介绍的反模式 180
第三部分　全 景 图
第9章　卫生之苦 184
9.1　为什么要研究编程卫生 184
9.1.1　极限编程需要好的编程卫生 185
9.1.2　编码标准可以避免反模式 185
9.2　小反模式：不可达的代码 186
9.2.1　名字匹配 186
9.2.2　命名标准 187
9.2.3　大括号和缩进 190
9.2.4　注释 191
9.2.5　制表符和空格 194
9.2.6　编辑器 194
9.3　小反模式：组织和可见性 195
9.4　小反模式：结构 198
9.4.1　基本面向对象理论 198
9.4.2　低级设计因素 198
9.4.3　异常 200
9.5　小反模式：泄漏和性能 200
9.6　测试的约定 201
9.7　建立一个好的风格指南 202
9.7.1　是买、是借还是偷？ 202
9.7.2　Contextual公司的一个示例风格指南 203
9.8　编码标准小结 205
第10章　可扩展性之苦 208
10.1　保证性能的好拓扑 208
10.1.1　同构组中的硬件分层 210
10.1.2　其他拓扑变种 211
10.2　反模式：事后再考虑性能 212
10.2.1　开发时不做性能规划 213
10.2.2　一些真实世界的例子 213
10.2.3　解决方案：做性能规划！ 214
10.3　反模式：往返通信 216
10.3.1　解决方案：缓存和外观 216
10.4　反模式：不好的负载管理 217
10.4.1　解决方案：工作负载管理 219
10.4.2　真正的负载平衡 220
10.5　反模式：混乱的会话管理 221
10.5.1　解决方案1：利用会话亲缘性分派 221
10.5.2　解决方案2：使用一个分布式状态管理服务 221
10.5.3　使用定制会话bean解决方案 222
10.5.4　使用定制实体bean解决方案 222
10.6　反模式：抖动调优 222
10.6.1　解决方案：使用合理的性能改进方法 223
10.7　驯服性能野兽 224
10.8　本章介绍的反模式 224
第11章　圆满的告别 227
11.1　反模式可以在很多层次上提供帮助 227
11.1.1　反模式促进职业发展 228
11.1.2　了解反模式可以改善程序 228
11.1.3　了解反模式可以使你成为一个更好的程序员 228
11.2　在过程中集成反模式 229
11.3　更上一层楼 230
附录A　反模式参照表 232
参考文献 238

序 说实在的，很少有计算机的书能把我迷住。有时，作者的睿智和对技术的精通不能不让我折服，Guy Steele的《Common LISP: The Language》就是这样，我记得很清楚，我是躺在风和日丽的夏威夷海滩上一口气把它看完的。有人可能会笑话我这么“滑稽”，也许他们笑我是有道理的，不过对我来说，Steele的每一章都写得那么引人入胜，让人忍不住想再看下一章。这本书真是让我爱不释手。 再就是一本看似小说的书，其中却不断的有令人惊奇的新发现。一方面它会牢牢地吸引住读者，让人沉迷其中，忘却周遭的现实世界；另一方面又用深刻的事实提醒着你，这些事实是你一直以来迫切搜寻的，稍纵即逝，尽管你知道应该认识到这些问题，但往往出于某种原因忽视了它们的存在，这本书则举起大锤让你警醒。Tom DeMarco的《The Deadline: A Novel About Project Management 》就是这样一本书。同样让我不忍释卷。 对我来说，Bruce Tate写的《Bitter Java》又是一个奇迹，它同样让我着迷。与DeMarco所说的绑架到摩罗维亚（译者注：这是作者所杜撰的一个奇境国家）一样，Bruce自己的种种“极限运动”：皮划漂流、在崎岖的山路上骑车，还有热气球冒险旅行，这些无不让我随着他们在急流中“上下颠簸”，“疾速挥浆”想看到下一个模式或陷阱。就像Steele的书一样，每看完一章后，我简直等不及看下一章；DeMarco的书让我手不释卷，看《Bitter Java》的感受也是一样，同样是舍不得放下。 要问我的建议？很简单，如果你没办法放下手边的事情，不能安排出全天的时间来静心地看这本书，那你先别开始看。如果天色已经很晚了，那我很同情你，因为你会忍不住熬夜把它看完，这样你明天肯定会疲惫不堪。如果你躺在夏威夷海滩上看这本书，最好用SPF 99的防晒霜。在你津津有味看书的时候，你会忘记时间，那么长时间地曝晒在烈日之下，对你的皮肤来讲实在是够受的。 《Bitter Java》确确实实把我震住了，希望你也一样。如果你要开发软件，或者要与开发软件的人共事，会发现每一章的内容都那么精辟，你会把它们引为经典，我的下一个设计评论中就打算引用Bruce的观点。《Bitter Java》里凝聚着作者的智慧和经验，这是每一个优秀软件工程人员梦寐以求的。我觉得第9章有关Java编码标准的内容可以自成一本书，要是有这样一本书，衷心希望所有Java程序员都能仔细阅读，精心钻研。 按照Bruce的观点，显然软件工程与在危险的急流上飞流直下可有一比，尽管不像在标准的4级急流中那样有生命危险，但是软件工程的失败对于你的生活（以至你所领导的人们的生活）来讲，可能同样是一场灾难。所以建议你仔仔细细地好好研究这本绝妙的指南。Bruce在这本短小精悍的书中，凝聚了一个能真正驾驭急流的高手的真知灼见，这些经验不可多得，讲述得清晰明了，读起来轻松有趣。 做好准备，尽可能地去体会这些危险之旅带来的震撼吧！不过别被吓倒了，遇到危险就狼狈得丢盔弃甲！ 祝你愉快！ Hays W. 襍kip* McCormick III，《AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis》的作者之一

Bruce Tate在IBM和一家创业型公司有14年的工作经验，其中一半时间都在担任Internet架构师。他还著有另外两本计算机书。

前 言 到了夏天，得克萨斯河水就几近干涸。为了寻找急流，漂流者不得不跟着暴风雨的脚步走。那是1996年夏天的一天，我和一个同伴晚上8点离开奥斯汀，冲入狂暴的风雨中，一直来到阿肯色州的Cossatot河。等我们到了那里，坏天气好像跟我们开了个残酷的玩笑，居然绕过这条河径直走了。我们筋疲力尽，失望之极，只好在河岸上扎营休息。那天晚上我们根本没有听到一丝雨声。 到了早上，我还是垂头丧气，头昏眼花地走出帐篷，然后几乎跌倒……在河里。Cossatot河素来就有涨水极快的坏名声，仅仅因为上游10英里处下了2个小时的雨，水位就突涨了6英尺。现在我们倒是可以漂流了，但是水位又太高。我们决定等第二天早上再来对付难度大的这一段，先到相对容易一些的上游漂流。原来水流迟缓的1级水域现在已经变成了汹涌的3级急流。指南上说这一段要漂流“4个小时”，但我们只花了20分钟就飞驰而下。“中间”河段更糟糕：湍急的河水已经达到4级，猛烈地咆哮着。经过仔细侦察，我们轮流在河岸上执守，一个人在河水中漂流时，要系着安全带，由另一个人在岸上监视情况。然后我们把皮划艇放在营地，徒步走下去，看看下面的河段情况怎么样。让我们惊讶的是，居然有几十个当地人在河岸旁放着躺椅，像看风景一样看着河面。以往他们看到的只是4级瀑布，如今这条河已经完全被可怕的大漩涡所笼罩。此前，我们很少看到当地人，他们在这里只是看有没有人出风头，有没有惊险的事情发生。这种景象让我们目瞪口呆，所以我和同伴也各自坐在一块大石头上开始看热闹。 追溯到2000年，尽管当时我的职位已经不低，而且待遇优厚，但我还是离开了IBM，去加入一家名叫allmystuff的创业型（startup）公司。当时经济已经开始衰退，但是在奥斯汀其他创业型公司纷纷垮台之际，这家公司却刚刚拿到了赞助。这家公司的企业运作并不取决于广告收入，所以尽管广告收入日薄，似乎也影响不大，另外allmystuff里集结了许多精兵良将。我加入公司之时，它的银行资金有一千万美元，不仅有固定客户，而且拥有着高新技术，这一切都预示着它很可能成为炙手可热的成功企业。我见过许多朋友都离开IBM大旗，转而投奔其他公司，虽然新公司的待遇不能比，也没有安全感，但是很有冒险性。我想反正在必要时还可以回去，所以面对着即将到来的黑暗，我迎头冲入到这场风暴中。 在奥斯汀新闻笑谈曾经红极一时的创业型公司都纷纷落马之时，allmystuff也开始在困境中挣扎。我们日以继夜地工作，为很少的几个客户部署解决方案。尽管我们的质量一流，有让人自豪的业绩记录，但最后还是被衰退的经济所累。风险投资者决定最好还是关门大吉，再找寻一种适应这种经济衰退局势的新概念东山再起。尽管这件事本身让人很难受，但是在我的职业生涯中，那个时期我学到的东西却是任何其他时候都比不上的。 就像Cossatot河岸上的当地人一样，如果一个冒险故事是我们身边发生的真事，很刺激，甚至很危险，那我们大多数人都无法抵挡它的吸引力。不论是看一个久负盛名的希腊悲剧故事，还是看像电视剧“生存者”（Survivor）这样一些最新的流行节目，我们的猎奇思想永无止境。程序员也不例外。我们很喜欢聊最近发生的冒险事情（我们把这称为“实境谈话”（merc talk）），这有很多原因。我有许多鲜活的工作记忆就是在allmystuff的乒乓球台边留下的。在那里我们讨论过管理哲学；讨论过代码基是不是已经失控；另外还讨论过，与日益复杂的JSP模型相比，有专门浏览器的XML是不是一种更简单的方案。我们还讨论过，眼看着进度不断推迟，图形化设计人员能不能把他设计的用户界面映射为越来越复杂的Java命令。正是这些讨论燃起了我的热情，促使我离开了原本安稳的职位，做着百万富翁的梦，投向这个待遇更低、没有安全感的新工作。这些经验使我成为一个更好的程序员、管理人员和架构师。 不记得在哪个场合下，前IBM主席John Akers曾说过，太多的人“整天都只是喝水聊天，无所事事”。我记得听了这话我们都很生气，他不知道，往往在喝水（或喝酒）时或者在乒乓球台边听到的东西会决定一个项目（甚至一个公司）的成败。在这里，必须听些程序员的故事，受些熏陶，因为这些会影响一生。我准备把其中一些故事放到《Bitter Java》这本书里。 再回到早先，那时我还没有加入allmystuff，正准备在一个会议上演讲。我报告的题目是“Bitter Java”。在会议期间，我遇到了一位著名的Java程序员，JSP的创始人之一。他告诉我曾经在Pamplona参加过“公牛奔跑”（run with the bulls）活动（译者注：这是一个很经典的活动，人们拼命地在公牛前面奔跑，一路上公牛会踩伤、踢伤或用角刺伤很多人，但人们还是乐此不疲，认为这是勇敢者的游戏），还被刺伤了。他还很起劲地给我解释他在参加公牛奔跑时的策略。我对他讲的不以为然。在Pamplona，早有无数的人告诉过我怎样避免被刺伤。我还向O. J. Simpson咨询过这方面的问题。每年都有数万个热衷于此的人参加，但只有十几个被刺伤。不过，慢慢地我有了想法：如果我要参加公牛奔跑，那我就会和他讨论。我想知道他是怎么计划的，他又怎么实施他的计划，哪里出了问题。这些信息我能用得上。后来发现，这个被刺伤的程序员正是allmystuff工程部的副总裁，他招募我帮助建立他的服务机构。再来说我的报告，尽管讲这个Pamplona故事可能会让我失去在allmystuff工作的机会，但我还是决定用这个故事来开始我的演讲。它充分体现了《Bitter Java》中的概念。要说能帮助避免一个微妙的圈套或陷阱，一个关于失败的故事往往抵得上10个成功的故事。这个故事牢牢地吸引住了听众，而且……我也得到了我的工作。 像许多程序员一样，我很喜欢极限运动。我们曾划着小艇遭遇危险，有时甚至遇到生命危险。William Neely曾经讲过漂流界很有名的一个法则：你注视一个急流的时间与它吞掉你的危险往往成正比。换句话说，如果看上去漩涡大到能吃掉你，它很可能就会吃掉你。漂流者有自己的一套办法来描述如何沿河下行。漂流指南中会指出一条路线，还会指出路线沿线以及路线之外的一些危险地方。指南中可能说，“接下来，你会看到中间有一块大石头，你要向左。如果误撞到右边，那这个急流就会成为‘终结者’，用残酷的方式告诉你错了。”我很清楚，即使你没有真正了解一条河的威力，你也很想知道哪些地方可能出问题。我想知道水下有没有岩石，有没有陷阱等着我。我想知道哪里可能遇到漩涡，怎么躲过瀑布底下的大石头。我想知道，是不是有人在这条河上丧生，那是怎么回事。如果没有足够的了解，就算有高超的技术，我往往也会回避，甚至顶着小船沿河岸一路走下去，就是不下水。 程序员（包括我）也是一样。我要了解应用和项目会在哪里失败。我要知道是不是与某个接口的通信太多了，所用的技术能不能解决这个问题。我得明白一个技术可能在哪里出问题，这个技术能不能扩展。 我深信，要想成功，软件开发中总少不了失败，而且势必要从中学习。我还没有看到哪个组织能系统地从错误中学习，并以正规、系统的方式仔细分析为什么要修改一个有问题的设计模式或过程。我曾经看过许多代码，但并不是所有代码都很好。我已经领会到“bitter Java”的魅力，希望你也一样。 致谢 Bitter Java概念于3年前萌生，最早是我在一个1小时的演讲中提出的。Braden Flowers帮助我完成了最初的定型，对于这一点，我对他实在是感激不尽。Bitter Java网站于2年后推出。尽管经过了一段时间的讨论（甚至争吵），Manning工作人员、诸位审校人员、一些朋友、另外一些作者还有我，最后还是建立了一个紧密协作的写作小组，大家横跨三大洲，终于在很短的期限内使这本书得以问世，不仅如此，如此高质量也超乎了我的想像。尽管我想逐个地提到每一个人的名字，但是由于太多的人做出了贡献，伸出过援手，实在无法一一列出大家的名字。 我原来还曾写过另外两本技术书，能得到Manning提供的世界一流的支持，真让我很受感动，也为之欣喜万分。我要感谢Marjan Bace两次：首先要感谢你耐心的指导，在整个过程的每一步都坚持力求完美，其次要感谢你热心地帮助我完善写作风格，帮助我修改草稿。你对文字娴熟的驾驭能力激励着我，你对别人的理解（包括你的顾客、你的竞争对手，还有你旗下的作者们）对我的影响也无以言表。 要特别感谢Ted Kennedy，他提供了卓越而专业的审校，而且在我最需要的时候给予了支持。还有许许多多的人花费了大量时间审阅这本书，这里要感谢你们大家：Jon Eaves、John Crabtree、John Mitchell、Steve Clafin、Sean Koontz、Max Loukianov、Greg Wadley、Tim Sawyer、Braden Flowers、Ted Neward、Eric Baker、Jon Skeet，还要特别感谢Juan Jimenez，你以后肯定会成为一个非常棒的编辑。你们的意见都有非凡的意义，你们的批评（无论尖锐还是温和）对我都有很大帮助，所以我才能把这本书写得更好。希望你们知道，尽管并非每条建议我都采纳，但我确确实实仔细地考虑过每一条意见，意见真的是太多了。真希望哪一天也能对你们写的书提提我的意见。 接下来要感谢我们的出版团队。首先要感谢Liz Welch，谢谢你的热心和高效率，还有高超的编辑水平（特别是你对正确性和一致性的执着）；还要感谢Susan Capparelle、Helen Trimes和 Mary Piergies，凭着你们非凡的能力，得心应手地推动

无封面