《程序员修炼之道》之所以在全球范围内广泛传播，被一代代开发者奉为圭臬，盖因它可以创造出真正的价值：或编写出更好的软件，或探究出编程的本质，而所有收获均不依赖于特定语言、框架和方法。时隔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 适合使用者的事物，都已经过良好设计。对代码来说，这意味着必须适应变化。 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：小步前进――由始至终