首页 > 科技 > 计算机 > 编程语言

程序员修炼之道：通向务实的最高境界（第2版）

作译者：云风

出版时间：2020-04 千字数：505 版次：01-01 页数：344

开本：16开装帧： I S B N ：9787121384356

换版：

纸质书定价：￥89.0

库存:有

分享到：

共有图书评论0条【查看评论摘要】

看了又看

{{data.bookName}}

￥{{data.price}}

内容简介

前言

上架建议

作者简介

编辑推荐

音视频专区

序	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：要对软件做测试，否则只能留给用户去做	230
无情地测试，不要等用户来帮你找 Bug。
42	基于特性测试	231
提示71：使用基于特性的测试来校验假设	231
基于特性的测试将会进行你从未想过的尝试，并会以你不曾打算采用
的方式操练你的代码。
43	出门在外注意安全	238
提示72：保持代码简洁，让攻击面最小	241
复杂的代码给 Bug 以滋生之沃土，给攻击者以可趁之机。
提示73：尽早打上安全补丁	243
攻击者会尽可能快地部署攻击，你必须快上加快。
44	事物命名	245
提示74：好好取名；需要时更名	249
用名字向读者表达你的意图，并且在意图改变时及时更名。
第8章  项目启动之前	251
45	需求之坑	252
提示75：无人确切知道自己想要什么	252
他们或许知道大概的方向，但不会了解过程的曲折。
提示76：程序员帮助人们理解他们想要什么	253
软件开发更像是一种由用户和程序员协同创造的行为。
提示77：需求是从反馈循环中学到的	254
理解需求需要探索和反馈，因此决策的结果可以用来完善最初的想法。

提示78：和用户一起工作以便从用户角度思考	255
这是看透系统将如何被真正使用的最佳方法。
提示79：策略即元数据	256
不要将策略硬编码进系统，而应该将其表达为系统的一组元数据。
提示80：使用项目术语表	259
为项目的所有特定词汇创建一张术语表，并且在单一源头维护。
46	处理无法解决的难题	260
提示81：不要跳出框框思考——找到框框	261
在面对无法解决的难题时，识别出真正的约束。可以问自己：“必须
这样做才能搞定吗？必须搞定它吗？”
47	携手共建	264
提示82：不要一个人埋头钻进代码中	267
编程往往困难又费力，找个朋友和你一起干。
提示83：敏捷不是一个名词；敏捷有关你如何做事	267
敏捷是一个形容词，有关如何做事情。
48	敏捷的本质	267
第9章  务实的项目	271
49	务实的团队	272
提示84：维持小而稳定的团队	272
团队应保持稳定、小巧，团队中的每个人都应相互信任、互相依赖。
提示85：排上日程以待其成	274
如果你不把事情纳入日程表，它们就不会发生。反思、实验、学习、
提高技能，这些事都应放入日程表。
提示86：组织全功能的团队	276
围绕功能而不是工作职能组织团队。不要将 UI/UX 设计者从程序员中
分离出去，也不要分开前端和后端；不要区分数据建模者和测试人员，
以及开发和设计。构建一个团队，这样你就可以渐进地不断迭代端到端
的代码。
50	椰子派不上用场	277
提示87：做能起作用的事，别赶时髦	279
不要仅仅因为别的公司正在那么干就采纳一项技术或采用一个开发
方法，而是要采用自己所处环境中对团队有效的东西。
提示88：在用户需要时交付	281
不要卡着流程要求，刻意等到几周甚至几个月后才交付。
51	务实的入门套件	281
提示89：使用版本控制来驱动构建、测试和发布	282
利用提交或推送来触发构建、测试、发布，利用版本控制的标签来
进行生产部署。
提示90：尽早测试，经常测试，自动测试	283
每次构建都跑一下的测试，要比束之高阁的测试计划有效得多。
提示91：直到所有的测试都已运行，编码才算完成	283
无须多言。
提示92：使用破坏者检测你的测试	285
在一个单独的源码副本中特意引入 Bug，验证测试能否将其捕获。
提示93：测试状态覆盖率，而非代码覆盖率	286
要识别并测试重要的程序状态，只测试一行行的代码是不够的。
提示94：每个 Bug 只找一次	286
只要人类测试者找到一个 Bug ，就应该是该 Bug 最后一次被人类
发现。从此之后，自动化测试完全可以发现它。
提示95：不要使用手动程序	287
计算机能一次又一次，按照同样的次序，执行相同的指令。
52	取悦用户	288
提示96：取悦用户，而不要只是交付代码	289
为用户开发能够带来商业价值的解决方案，并让他们每天都感到愉快。
提示97：在作品上签名	290
过去的工匠在为他们的作品签名时非常自豪，你也应该这样。
53	傲慢与偏见	290
跋	292
提示98：先勿伤害	293
犯错在所难免，确保犯错后没人会因此受难。
提示99：不要助纣为虐	294
因为这样做你也有变成纣王的风险。
参考文献	295
练习的参考答案	297
译者跋	312

序
我还记得 Dave 和 Andy 第一次在推特上谈论这本书的新版的那一刻——这可是一条大新闻。在编程社区，所见之处都是对这条大新闻兴奋的回应，人们的期待塞满了我的信息流。二十年过去了，《程序员修炼之道》这本书的地位不逊于当年。
承载这样一段历史的一本书，能引起这样的反响，本身就说明了很多问题。为了写这篇序，我有幸在尚未出版前阅读了本书，读后我就明白了它为什么会引起这么大的轰动。本来，一本书被冠以技术图书之名，给人的印象应该是不太好的。因为技术图书常常令人生畏——充斥着深奥的词汇、晦涩的术语和令人费解的例子，不经意间就会让你觉得自己很愚蠢。而且，作者越有经验，就越容易忘记初学者在学习新概念时的感觉。
Dave 和 Andy 的作品，却能透出那种只有刚刚学到这些课程的人才会有的兴奋感，尽管他们已有几十年的编程经验，却战胜了写出这种感觉的挑战。他们不会居高临下地指指点点，不会假定你是个专家，甚至不认为你已读过本书第一版，仅仅把你当成想要变得更好的程序员而已。他们不惜用整本书的篇幅来帮助你达到目标，一步一个脚印。
公平地说，在这方面，他们在过往已经成绩斐然。最初的本书第一版，包含了许多具体的例子、新想法和实用的技巧，可以帮助你修炼编程所需的“肌肉”和“大脑”，这些东西到今天仍然适用。但是，这次在新版图书中，又有了两项改进。
第一项显而易见：删除了一些较老的引用内容和过时的例子，增补了大量新鲜、现代的内容。循环不变式或构建机这样的例子已经看不到了。Dave 和 Andy 保留了第一版书中的重要内容，以确保相应的课程依然有效，而且读者也不必受旧示例的干扰。对于像 DRY（不要重复自己）这样的旧思想，上面的灰尘已被掸去，并且涂上了一层新油漆——这样做真的让其熠熠生辉。
而第二项，才是这次新版图书发布真正令人兴奋的地方。在写完本书第一版后，他们有机会思考自己想要说什么，想让读者获得什么，以及读者是如何接受这些信息的。他们得到了这些课程的反馈，也看到了读者在哪里被卡住、有什么需要改进，以及哪些内容被误解。在这本书通过全世界程序员的双手和心灵传播的二十年间，Dave 和 Andy 研究了这些回应，并且形成了新的想法和理念。
他们认识到自主权的重要性，并且意识到，相比大多数其他专业人员，开发者或许更能为自己做主。他们以简单而深刻的启示开始这本书：“人生是你的。”这唤起了我们自己的力量，它就蕴含在我们的代码库、工作和职业生涯中。这也为本书的其他内容定下了基调——它不仅仅是又一本充满代码示例的技术图书。
这本书必定会在摆满各种技术图书的书架上脱颖而出，因为它理解身为一名程序员到底意味着什么。编程关涉诸事——尽量减少未来的痛苦，让队友更轻松，做错事情后能够重新振作起来，养成良好的习惯，以及理解工具集。编程只是程序员世界的一部分，而这本书探索了整个世界。
我在思考编码之旅上花了很多时间。我不是从小就开始接触编程的，大学里也没学过编程课。可以说，我的青少年时光并没有花在“摆弄”科技上，直到二十来岁的时候才进入了编程的世界，因而亟须想明白一件事情：成为一名程序员意味着什么。编程社区与我曾经身处的其他社区非常不同。其独特之处在于，人们无不醉心于学习和实践，这既令人生畏，又让人耳目一新。
这对我来说，真像进入一个全新的世界。就算去到一个新城镇，也有必要了解邻居、挑选杂货店、找到最好的咖啡店。我花了一段时间来了解地形，找到了最有效的路线，避开了交通最繁忙的街道，并且知道了什么时候交通可能会出问题。等到天气变化，我又要去置办应季的新衣。
来到一个新城镇的头几周，甚至是头几个月，可能会很害怕。如果有一个已经在这里住了一段时间的邻居，而且他知识渊博又友好，那不是再好不过的事情吗？谁能带你四处参观，谁能领你去那些咖啡店？当然是一个在当地待了足够长时间的，了解当地文化、当地脉搏的人。这样你不仅有家的感觉，还能成为一个同样有贡献的成员。Dave 和 Andy 就是这样的邻居。
一个准新人，更容易对成为程序员的过程，而不是对编程的行为不知所措。因此，必须对整个心态做一次切换——改变习惯、行为和期望。仅仅知道如何编程，并不会让你成为一名更好的程序员，在这个过程中必须经历有意识和深思熟虑的实践。好在现在有了这本书，可以有效地指导你成为更好的程序员。
但不要搞错了——这本书不会告诉你编程应该是怎样的，它并没有使用那种哲学或审判的方式，它只是简单、明了地告诉你，什么是务实的程序员——他们如何操作、如何处理代码。作者让你自己决定是否想成为其中的一员。如果你觉得不适合，也没有人会怪罪你。但如果你决定成为其中的一员，作者就是你的友好邻居，会陪伴左右、为你指路。
Saron Yitbarek
CodeNewbie 创始人及 CEO 
Command Line Heroes 主办者

新版前言
在20世纪90年代，我们在与一些项目存在问题的公司合作时，发现总是在对每个人说同样的话：也许你应该在发布之前先测试一下。为什么代码只能在 Mary 的机器上构建？为什么没有人问一下用户呢？
为了节省与新客户打交道的时间，我们开始做笔记。这些笔记最终变成了《程序员修炼之道》这本书。令人惊讶的是，这本书似乎引起了大家的共鸣，在过去的二十年间，这本书一直很受欢迎。
但是二十年对于软件领域来说已经过了好几代。如果一个开发者从 1999 年直接穿越到今天的团队中，面对这个陌生的新世界一定会备感挣扎。但20世纪90年代的世界对今天的开发者来说同样陌生。书中所引用的 CORBA、CASE 工具，以及索引、循环这些东西，放在今天，充其量不过略显古雅有趣，而更多的会给人带来困扰。
与此同时，二十年对常识没有丝毫影响。技术可能改变了，但人没有。实践和方法中的闪光点，在今天看来光芒依旧。在这些方面，本书保鲜如初。
所以，当我们要出版这本二十周年纪念版的时候，必须做出抉择——是回顾和更新前一版中引用的技术后就大功告成，还是充分借鉴这平添的二十年丰富经验，重新审视前一版所推崇的实践背后的种种假设。
最终，我们两者都做了。
因此，这本书有点像忒修斯之船 。书中大约三分之一的主题是全新的，而其余的大部分都被部分或全部重写了。我们的目的是，让内容变得更清晰、更贴切，并在某种程度上不受时间的影响。
我们做了一些艰难的决定。删除了参考资料附录，这样做既因为它无法持续更新，也因为当你有此需要时很容易就能搜索获得。我们重新组织了与并发有关的主题，这是因为考虑到当前有着大量的并行硬件，却缺乏处理并行的好方法。我们还添加了一些内容来反映不断变化的认知和环境，从我们帮助发起的敏捷运动，到对函数式编程语境的日益接受，再到对隐私和安全性方面日益增长的需求。
然而有趣的是，我们之间关于版本内容的争论比写第一个版本时要少得多。重要的东西更容易辨别，这已是我们的共识。
无论如何，这本书最后就是这个样子了，请享用吧。你也许可以从中吸取一些新的做法，也许会觉得我们建议的某些东西是错的，不妨把它们都带到你的工作中去，然后给我们反馈。
但是，最重要的是，记住过程要开心。
【这本书是如何组织的】
这本书是许多短小主题的合集。每一个主题都针对特定的话题而独立成章。你会发现大量的交叉引用，这有助于把各个主题连贯起来。你可以以任意次序随意阅读这些主题——这不是一本需要从头到尾阅读的书。
偶尔你会看到一个写有提示n的框起来的标签块（比如位于第XVII页的提示1：关注你的技艺）。这些提示不仅是文中的重点，在我们眼里也是一条条生命——我们每天都赖以为生。
我们已尽可能适时地在书中加入了练习和挑战。练习通常有相对简单的答案，而挑战则更加开放。为了让你理解我们的思维方式，在附录里我们列出了这些练习的答案，但是拥有唯一正确答案的问题并不多。挑战或许能用于高级编程课程中的小组讨论，或许能作为论文写作的基础。
本书还有一个简短的参考文献，列出了我们明确引用的图书和文章。
【名字有什么含义】
“我用一个词，”矮胖子相当傲慢地说，“总是同我想要说的恰如其分的，既不重，也不轻。”
—— 路易斯·卡罗《爱丽丝镜中奇遇》
在整本书中，你会发现各种各样的行话——要么原本是完好的英语单词，却被曲解为技术词，要么是一些可怕的合成词，由那些对语言充满怨恨的计算机科学家赋予其意义。当我们第一次使用这些行话时，会尝试定义它们，或者至少对其含义给出解释。当然，肯定还有漏网之鱼，而且像对象和关系型数据库这种已被广泛使用的，再下一次定义就有点画蛇添足了。如果你遇到一个以前没见过的术语，请不要跳过它，不妨花点时间去查一下，可以在网上查，也可以在计算机科学的课本上查。如果有机会还可以给我们发邮件投诉，这样我们就可以在本书下一版中增加一个定义。
既然话已至此，我们决定报复一下计算机科学家。有时候，明明有一些非常好的术语，对某个概念表达得很好，但我们却决定不使用这些术语。为什么？因为现有的术语通常局限于特定的问题领域，或者特定的开发阶段。而本书的基本哲学之一就是，我们推荐的大多数技术都是通用的：例如模块化，它就能同时适用于代码、设计、文档和团队组织。当某个传统术语被拿来在更广泛的场景下使用时，却会造成困惑——我们似乎无法摆脱该术语从最初就开始背负的历史包袱。当这种情况发生时，我们只好发明自己的术语，助纣为虐地让语言继续堕落。
【第二版鸣谢】
在过去的二十年里，有成千上万关于编程的有趣对话曾让我们开心不已，其中不乏在会议、课程，甚至是飞机上与人们的偶遇。每一次经历，都会加深我们对开发过程的理解，并为此版本的更新添砖加瓦。感谢所有人（而且，当我们犯错误的时候，请继续提醒）。
感谢本书 Beta 测试过程的参与者，是你们的问题和评论，帮助我们把事情解释得更清楚。
在进行 Beta 测试之前，我们曾与一些人分享过本书。感谢 VM (Vicky) Brasseur、 Jeff Langr、 Kim Shrier 给予的详细评论，感谢 José Valim 与 Nick Cuthbert 的技术审核。
感谢 Ron Jeffries 让我们用数独的例子。
非常感谢培生集团的人，是他们让我们以自己的方式来创作这本书。
特别感谢不可或缺的 Janet Furlow，她掌控着一切，让我们的工作没有走样。
最后，向所有在过去的二十年里一直致力于让编程变得更好的务实的程序员们发出一声呐喊：再接再厉，更创二十年辉煌。

第一版前言
本书将帮助你成为更好的程序员。
不论你是独立开发者，还是大型项目团队的一员，或是同时与许多客户共事的顾问，都无所谓。本书旨在告诉你，作为个体如何更好地完成工作。这本书不是理论书——我们专注于实践的话题，利用经验来做出更明智的决定。务实（Pragmatic）这个词来自拉丁语 pragmaticus ——“精通业务”，该词又来源于希腊语 πραγματικ??，意思是“适合使用”。
这是一本关于实干的书。
编程是一门技艺。简单地说，就是让计算机做你想让它做的事情（或是你的用户想让它做的事情）。作为一名程序员，你既在倾听，又在献策；既是传译，又行独裁；你试图捕获难以捉摸的需求，并找到一种表达它们的方式，以便仅靠一台机器就可以从容应付。你试着把工作记录成文档，以便他人理解；你试着将工作工程化，这样别人就能在其上有所建树；更重要的是，你试图在项目时钟的滴答声中完成所有这些工作。你每天都在创造小小的奇迹。
编程是一项艰难的工作。
想帮你的人可不少——工具供应商在吹嘘他们家产品所创造出的奇迹，方法论大师承诺他们的技术可以为结果做出保证，每个人都声称他们用的编程语言是最好的，每个操作系统都自诩包治百病。
当然，这些都不是真的，哪有什么简单的答案。没有最好的解决方案，无论是工具、语言还是操作系统；只在特定的环境下才有所谓更合适的系统。
这就让务实主义有了用武之地。你不应该拘泥于任何特定的技术，而应该拥有足够广泛的背景和经验基础，以便在特定的情况下选择合适的解决方案。你的背景来自对计算机科学基本原理的理解，而你的经验来自广泛的实际项目。理论结合实践会让你变得强大。
调整方法去适应当前的情况和环境。对所有影响项目因素的相对重要性做出判断，并通过经验找到适当的解决方案。随着工作的进展，你要不断地这样做。务实的程序员不仅把工作做完，并且做得很好。
【谁应该读这本书】
本书的目标读者是那些希望成为更高效、多产的程序员的人。也许你现在感到沮丧，因为似乎没能发挥自己的潜力；也许你已经注意到，有些同事似乎正在利用工具让自己的效率比你更高；也许你在现在的工作中使用的是较老的技术，你想知道如何为工作引入新的想法。
我们不会假装拥有所有（或是绝大部分）的答案，也不会假装我们的每个想法都适用于所有情况。我们只能说，如果你遵循我们的方法，你将快速获得经验、提高生产力，并且更好地理解整个开发过程。最终，你会写出更好的软件。
【是什么造就了务实的程序员】
每个开发人员都是独特的，有各自的优势和劣势，以及偏好和厌恶的东西。诚如随着时间的推移，每个人都将打造自己的个人环境。这种环境将像程序员的爱好、衣服或发型一样，能强烈地反映出他或她的个性。然而，作为务实的程序员，你们会共有许多如下特征：
.早期的采纳者/快速的适配者
你对技术和技巧有一种直觉，喜欢尝试。当接触到新东西时，你可以很快地掌握它们，并把它们与其他的知识结合起来。你的信心来自经验。
.好奇
你倾向于问问题。这真不错——你怎么做到的？你对那个库有意见吗？总在听人说起的量子计算到底是什么？符号链接是怎么实现的？你热衷于收集各种细微的事实，坚信它们会影响自己多年后的决策。
.批判性的思考者
你在没有得到证实前很少接受既定的现实。当同事们说“因为就该这么做”，或者供应商承诺会解决所有的问题时，你会闻到挑战的味道。
.现实主义
你试图理解所面临的每个问题的本质。这种现实主义让你对事情有多困难、需要用多长时间有一个很好的感知。一个过程应该很难，或是需要点时间才能完成，对这些的深刻理解，给了你坚持下去的毅力。
.多面手
你努力熟悉各种技术和环境，并努力跟上新的进展。虽然目前的工作可能要求你在某个专门领域成为行家，但你总是能够进入新的领域，迎接新的挑战。
我们把最基本的特征留到最后。所有务实的程序员都有这个特征。它足够基本，完全可以作为提示来加以声明。
提示1	关注你的技艺
我们觉得，如果你不关心怎么把软件开发好，那么软件开发领域就再也没什么好谈的事情了。  
提示2	思考！思考你的工作
为了成为一名务实的程序员，我们要求你在做事的时候，思考一下自己正在做什么。这不是对当前实践做的一次性审计——而是对每天里每一个项目所做的每一个决定进行的批判性评估。不要用自动辅助驾驶系统偷懒，而是要不断地思考，即时地批判自己的工作。IBM 公司的座右铭“思考！”，实属每个务实程序员的真言。
如果你觉得这听起来很困难，那么你就表现出了现实主义的特征。这会占用你一些宝贵的时间——可能是已经处于巨大压力之下的时间。当然会有回报，你能更积极地投入喜欢的工作，对越来越多的学科有掌控感，对不断进步产生愉悦感。从长期来看，时间投资将得到回报，因为你和你的团队将变得更高效，能编写出更容易维护的代码，并且在会议上花的时间更少。
【务实的个体，大型的团队】
有些人认为在大型团队或复杂的项目中没有个性的空间。“软件是一门工程学科，”他们说，“如果团队成员个体自行其是，软件就会崩溃。”
我们强烈反对这种看法。
诚然，软件构造有工程的成分。然而，这并不妨碍个体的技艺。想想中世纪在欧洲建造的大教堂，每一座都需要数千人年的努力，时间跨度长达几十年。从中吸取的经验教训被传递给下一代的建造者，最终一代代累积的造诣推动了结构工程的发展。而木匠、石匠、雕刻师和玻璃工人都是手工艺人——通过吃透工程要求，其创造所体现出的整体水准，已远超建筑中纯机械的部分。正是他们对个人贡献的信念支撑着这些项目：我们，采集的只是石头，却必须始终展望着未来的大教堂。
在一个项目的整体结构中，总有个性和技艺的空间。考虑到软件工程的当前状态，这一点尤为正确。今天的土木工程师，很难接受中世纪大教堂建造者使用的技术——百年后我们的工程看上去也一样古老，而我们的技艺仍将受到尊重。
【这是一个连续的过程】
一位游客在参观英格兰伊顿公学时，询问园丁是如何把草坪修剪得如此完美的。“那很简单，”园丁回答说，“你只要每天早上拂去露水，隔天修剪一次，一周再滚压一次就行了。”
“就是这些吗？”游客问。“就这些，”园丁回答，“这样做上五百年，你也会有一片漂亮的草坪。”
伟大的草坪需要每天的点滴护理，伟大的程序员也是如此。管理顾问喜欢在谈话中抛出“改善（Kaizen）”这个词。“改善”是一个日语术语，意思是不断地做出许多小的改进。这被认为是日本制造业生产率和质量大幅提高的主要原因之一，并被全世界广泛效仿。改善也适用于个人。每一天都要努力打磨你的技能，并往技能库里添加新的工具。与伊顿草坪不同，你会在几天内就看到效果。几年下来，你会对成果惊讶不已——经验业已开花结果，技能早就茁壮成长。

查看更多 > 图书评论

暂无评论

发表图书评论

评论标题：
评论内容：
验证码：: 看不清楚
点击刷新
: 您还没有登录，请登录后再评论。
点击“登录”

购买过本书的顾客还买过

{{data.bookName}}

￥{{data.price}}