编辑推荐

适读人群 ：无论你是一个新的程序员，一个有经验的程序员，还是一个负责软件项目的经理，都会通过本书获得个人生产力、准确性和工作满意度的提高，从中习得的学习技能、习惯和态度，都将是你在职业生涯中获得长期成功的基础。

屹立 20 年影响力大作，成功案例数以千万计，凌驾于任何语言|框架|方法之上。

面向未来重写全部内容，从程序员责任与职业发展，到灵活|易适配|可重用架构。

53个核心话题|99个高能提示，阐明软件开发走向卓越之路及途中各种典型陷阱。

编程界传奇人物云风操刀翻译，至理|奥义|案例|技巧之原著精微，无不掘至毫巅。

与“软件腐烂”做斗争

持续学习

避免知识重复的陷阱

写出有弹性、动态、适配性强的代码

驾驭基本工具的力量

避免依赖巧合编程

学习真正的需求

解决并发代码的底层问题

防范安全漏洞

建立务实程序员构成的团队

对你的工作和事业负责

无情而有效地做测试，包括基于特性的测试

组建务实的入门套件

取悦你的用户

内容简介

《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔20年的新版，经过全面的重新选材、组织和编写，覆盖哲学、方法、工具、设计、解耦、并发、重构、需求、团队等务实话题的最佳实践及重大陷阱，以及易于改造、复用的架构技术。本书极具洞察力与趣味性，适合从初学者到架构师的各阶层读者潜心研读或增广见闻。

作者简介

译者云风（真名吴云洋），曾任网易杭州研究中心总监，是网易《大话西游》《梦幻西游》等知名游戏的主要开发者；2011 年与前网易 COO 詹钟晖联合创办简悦（EJOY）游戏公司，兼任 CTO，现该公司已被阿里收购；在互联网、游戏界拥有较高技术影响力，常年发表博客文章，并著有《游戏之旅》及《Effective C（评注版）》。

章节目录

序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

适合使用者的事物，都已经过良好设计。对代码来说，这意味着必须适应变化。

9DRY——邪恶的重复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

纯文本不会过时。它能够让你的工作事半功倍，并能简化调试和测试工作。

17Shell游戏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

程序员修炼之道(第2版)是2020年由电子工业出版社出版,作者AndrewHunt。

得书感谢您对《程序员修炼之道(第2版)》关注和支持，如本书内容有不良信息或侵权等情形的，请联系本网站。