《程序员修炼之道》之所以在全球范围内广泛传播,被一代代***奉为圭臬,盖因它可以创造出真正的价值:或编写出更好的软件,或探究出编程的本质,而所有收获均不依赖于特定语言、框架和方法。时隔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