读书笔记 · 约 16,838 字 · 预计推送 2 部分

《The Pragmatic Programmer》20 周年版精选：提炼仍有效的原则与已过时的建议（主题精读） 未开始

目录

题记与说明

0. TL;DR

《程序员修炼之道》1999 年第一版到 2019 年 20 周年版的改版策略，作者在新版序言里自己讲清楚了：

"[W]e had to make a decision. We could go through and update the technologies we reference and call it a day. Or we could reexamine the assumptions behind the practices we recommended in the light of an additional two decades' worth of experience. In the end, we did both."
（我们要么更新技术引用就完事，要么用多出来的二十年经验重新审视那些实践背后的假设。最后我们两个都做了。）——新版前言，经 dev.to 书评转引

对照本次拉取的两份 tips 清单：第一版 70 条 → 第二版 100 条。"过时"不是抽象判断，而是可逐条指认的：Use a Single Editor Well→Achieve Editor Fluency（不再强推单一编辑器）、Always Use Source Code Control→Always Use Version Control（术语现代化）、第一版的 Write Code That Writes Code（代码生成）整条消失；DRY 从绝对命令弱化为"某些复用是合理的"；继承式 OO 被新版自己打脸成 Don't Pay Inheritance Tax。而哲学层（责任、能动性、DRY-as-knowledge、ETC、tracer bullets、小步快走、反馈循环需求）跨版本保留且在 HN/Reddit 的 2026 年讨论中仍被独立印证。真正过时的是具体技术绑定和 90 年代 OO 正统，不过时的部分则常常"过时得太成功"——因为变成常识了（HN：Seinfeld is Unfunny 效应）。对 2026 年读者，这本书最大的缺口不是错，而是沉默：AI/LLM 辅助开发在官方书页中无任何着墨。

1. 核心问题

这组材料共同回答：一本 1999 年的软件经典，二十年后重写（20 周年版，2019-09，320 页，新增+重写贯穿全书），到 2026 年（出版又过了 7 年、AI 编程工具爆发后）哪些原则仍然成立、哪些建议已经过时或被作者自己推翻？拆成四个子问题：

  1. 改版逻辑：20 周年版到底改了什么？（哪些是术语更新、哪些是立场反转、哪些整条删除）
  2. 仍然有效：哪些原则在两版之间被保留，且在 2019-2026 的社区讨论中仍被独立印证为"每天在用"？
  3. 已经过时：哪些具体建议被第二版自己改写/删除，哪些被社区指认过时？
  4. 结构性批评：除了内容新旧，这本书作为" advice 文本"本身有什么被反复诟病的质量问题（可操作性、组织、读者时机效应）？

2. 主要主张

2.1 改版逻辑：一半更新技术，一半重审假设

"When you write a book that's so well-received, doing a second version --- the only place you can go is down."

2.2 仍然有效的原则（三重印证：跨版本保留 + 书评人日常使用 + 社区 2026 仍在引用）

  1. 责任与能动性。第一版 Tip 1/2（Care About Your Craft / Think! About Your Work）原样保留；第二版新增 Tip 3：
"You Have Agency — It's your life. Grab hold of it and make it what you want."（官方 tips 页）

danlebrero 笔记记为 "You own your life"。HN 高赞（martininmelb）："That book has probably shaped my thinking and coding more than any of the others above."

  1. DRY 的正确读法：知识的唯一权威表示，不是反复制粘贴。官方定义在两版间保持一致（Tip 15，2e）：
"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

leverstone 书评明确说 DRY 与正交性是他"每天在用"的东西，且被 2e 重构为避免知识的重复（文档、注释、沟通中都要单一事实源）。dev.to 确认 2e 给 DRY 加了"某些复用是合理的"的限定——定义没变，应用边界变了。

  1. ETC（Easier to Change）作为好设计的元判据（2e Tip 14）：
"Good Design Is Easier to Change Than Bad Design — A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing."

这是 2e 的新表述（1e 编号里没有这条独立 tip），leverstone 说这是他日常最重要的决策工具：需求不明时主动缩小范围以保持系统可变。

  1. Tracer Bullets（曳光弹）与 Prototype 的区分（Tip 20/21，两版保留）。HN 用户 aerophilic："I don't think a month goes by that I don't quote this concept to a group or individual." leverstone 强调两者目的不同：曳光弹是打通全链路的薄切片并保留，原型是为学习而丢弃。
  1. "没有最终决定"+ 避免算命（Tip 18 "There Are No Final Decisions"、Tip 43 "Avoid Fortune-Telling — Only look ahead as far as you can see"）。与当前敏捷/演进式架构共识完全一致。
  1. 小步快走 + 反馈（2e Tip 42）：
"Take Small Steps—Always — Small steps always; check the feedback; and adjust before proceeding."

这条在 agent 时代的价值反而上升（见 §7）。

  1. 需求在反馈循环中习得（2e Tips 75-77："No One Knows Exactly What They Want" / "Programmers Help People Understand What They Want" / "Requirements Are Learned in a Feedback Loop"）。danlebrero 笔记补一句 2e 原话："The only requirements document is working code." leverstone 把整章总结为"requirements learning"。
  1. 基本工程卫生仍然不普及。HN 帖子里最有信息量的一组评论反而是反面证词：jkaptur 抱怨"版本控制的论证显得多余"，立刻被 jsperson 打脸——他接手四大咨询公司的项目，"最新代码在哪？"答案："on the production server"（在生产服务器上），"We could have checked it into VC, but didn't want to take the time."；Godel_unicode 的团队被告知"using git is over-engineering"；thebouv 描述十亿美元公司的"先上生产、最后才提交版本库"流程。结论：Tip 28（Always Use Version Control）这类"显得过时的基础建议"在 2026 年仍然有现实针对性——过时的是论证的必要性感知，不是实践的普及度。
  1. 测试哲学（2e Tip 66 "Testing Is Not About Finding Bugs — A test is a perspective into your code"；Tip 67 "A Test Is the First User of Your Code"；Tip 94 "Find Bugs Once"——人工发现的 bug 应转为自动化回归；Tip 89 "Use Version Control to Drive Builds, Tests, and Releases" 把版本库提交作为构建/测试/发布的触发器，即 CD 的表述）。
  1. 调试心态（Tip 29 "Fix the Problem, Not the Blame"、Tip 33 "'select' Isn't Broken — It is rare to find a bug in the OS or the compiler..."）。HN 用户 beat："I still quote from it regularly. ('SELECT isn't broken!')"

2.3 已过时或被第二版自己改掉的建议（可逐条指认）

依据：官方 2e 100 条清单 × GitHub 社区摘要的 1e 70 条清单（均为本次拉取），加上 dev.to / leverstone 的对比观察。注意 1e→2e 编号整体位移，"1e 无此条"以社区摘要为准，个别可能属改写而非新增。

#第一版（1999）第二版（2019）变化性质
1Tip 22 Use a Single Editor Well（用好一个编辑器）Tip 27 Achieve Editor Fluency（达到编辑器熟练度）立场反转：从"专精一个编辑器"的编辑器忠诚度建议，改为工具中立的熟练度要求（dev.to 同样确认 plain text 章不再强推单一编辑器）
2Tip 23 Always Use Source Code ControlTip 28 Always Use Version Control术语现代化（dev.to："got a major update"）
3Tip 29 Write Code That Writes Code（写会写代码的代码——代码生成）官方 100 条清单中无对应条目整条消失。90 年代的代码生成/元编程乐观主义被撤下；讽刺的是 2020s 的 LLM 代码生成让这个方向部分回归，但形态完全不同（自然语言→代码，而非模板→代码）
4DRY 的绝对化应用（1e 语境下常被读成"消灭一切重复"）2e 保留定义但"clarify that certain reuse is warranted"（dev.to）应用边界收缩：承认为解耦而复制可能优于制造错误抽象（与 2010s 社区"错误抽象比重复更贵"的共识合流）
51e 以继承为中心的 OO 复用2e Tip 51 Don't Pay Inheritance Tax — Consider alternatives that better fit your needs, such as interfaces, delegation, or mixins；Tip 53 Has-A Trumps Is-A立场反转：新版自己承认继承作为默认复用机制是错的。danlebrero 笔记里还记了 2e 对 OO 封装的批评（"Big reason that OO systems are hard to change: encapsulation"）和转向数据变换的视角（Tip 49 "All programs transform data, converting an input into an output"）
6共享可变状态 + 同步原语Tip 57 Shared State Is Incorrect State；Tip 59 用 Actors表述从"小心同步"升级为"共享状态本身即错误"——与 Actor/消息传递/CSP 的现代化对齐
71e 无Tip 19 Forgo Following Fads，引 Neal Ford："Yesterday's Best Practice Becomes Tomorrow's Antipattern."新增的元原则：本身就是对"当年的最佳实践会过时"的自觉
8—Tip 11 English is Just Another Programming Language新增：把写作/文档纳入 DRY、ETC、自动化的管辖——对 2020s 文档即代码、prompt 即代码的实践有直接映射

社区指认的"技术性过时"（非作者自改）：leverstone 认为并发章开头好、后面的具体技术"feel disjointed and somewhat dated"（散乱且有点过时），不如专门书籍；jkaptur 点名 blackboard（黑板）模式"decidedly hasn't taken off"（显然没有流行起来），并吐槽"推荐那些完全没被业界采纳的东西时很出戏"（HN #61）。Evanbenn 提出"Redis 像现代的黑板"作为缓刑。

2.4 结构性批评：这本书作为 advice 文本的质量问题（HN 103 条评论归纳）

  1. "Goldilocks 式不可操作"（tedunangst，HN #39）：建议全是"实现需要的特性但别太多、写点文档但别太多"式的中庸，"You read it, and oh yes, very wise, but not really helpful? Not much here would be useful in resolving a dispute between two programmers."。TeMPOraL 补刀："'moderation' 类建议 carries nearly zero bits of information"（信息量接近零）——当然、我不想做过头，但多少算过头？书的回答是让你自己想。
  2. 因太成功而显得"常识"（rubinelli，HN #54）："It's one of those books that is so widely read, that most of the lessons become common knowledge." steveklabnik 给出电视编剧 trope 名：Seinfeld Is Unfunny——开创者的内容被后来者稀释后反显平庸。WalterBright 的版本最精辟："When I finally read Romeo and Juliet, I was surprised at how many cliches and tropes were in it."（读到《罗密欧与朱丽叶》才发现那些陈词滥调是它发明的。）
  3. 组织散乱、标题费解（gmiller123456，HN #96，自称未通读只略读过多次）："the book is poorly organized and really just seems to be a really long rant. It's impossible to tell what a chapter or section is about from its heading." leverstone 也抱怨：敏捷建议散落在 topic 27/48/50，"Coconuts Don't Cut It"这种标题根本看不出在讲"不要盲目照搬方法论"。
  4. 阅读时机效应（SloopJon，HN #87）："I didn't get much out of The Pragmatic Programmer myself. Maybe if I'd read it ten years earlier, it would have been my Code Complete."——早读者给五星，晚读者觉得全是废话，两边都对。
  5. 语境错配（milesvp，HN #43）：在"胶带+铁丝"式的救火维护岗位上读这本书，前几章完全没有处理"真正的务实"（每天被告警叫醒的那种），"I couldn't finish it... I associate it with too much PTSD from that time in my life."
  6. 行业现实主义反驳（ilovecaching，FAANG 背景，HN #38）："Literally the only thing that matters is moving fast. Technical debt is just the price of scaling and beating the competition."获 taneq 回应：现金流稳定、不疯狂扩张的公司，天平会摆回代码质量——书的原则默认了"代码有长期生命"这一前提，前提不成立时建议悬空。
  7. 作者方的信号：ralphc（HN）转述 The Changelog 播客 352 期——"Hunt and Thomas themselves don't really recommend it anymore. Large parts of the industry have changed."（他们自己也不再推荐第一版了。）另 sramsay 提到二十年不更新的"法律原因"传闻——传闻，未核实。

3. 方法

4. 数据与证据

  1. tips 数量对照（本次直接验证）：第一版 70 条（GitHub 社区摘要最大编号 Tip 70）；第二版 100 条（官方 tips 页 Tip #1 "Care About Your Craft, pg. xxi" 到 Tip #100 "It's Your Life... AND HAVE FUN!, pg. 287"）。搜索摘要中"第二版 78 条"的说法与官方页矛盾，判为错误——二手摘要不可信的实例。
  2. 新旧 tip 名称 diff 证据（两份清单均本次抓取）：§2.3 表格全部条目。
  3. HN 讨论规模：item 21016664，524 points，103 条评论（Algolia API 返回 JSON 55KB，全部解析阅读）。
  4. 关键引文（全部见上文各节，均注明出处链接）：
    • 新版前言"we did both"（dev.to 转引）；
    • DRY 定义（官方 Tip 15）；ETC（官方 Tip 14）；
    • Don't Pay Inheritance Tax（官方 Tip 51）；
    • "Yesterday's Best Practice Becomes Tomorrow's Antipattern."（官方 Tip 19 引 Neal Ford）；
    • 圣埃克苏佩里："Perfection is achieved not when there is nothing left to add but when there is nothing left to take away."（danlebrero 摘自 2e 第 8 章章首）；
    • "The only requirements document is working code."（danlebrero 笔记）；
    • "A team that doesn't continuously experiment with their process is not an agile team."（danlebrero 笔记）；
    • 2e 道德罗盘（postface）："Have I protected the user?" / "Would I use this myself?" 与 Tip 98 First, Do No Harm、Tip 99 Don't Enable Scumbags — Because you risk becoming one, too.（官方 tips 页）。
  5. 2026 年相关性存疑的直接证据：Reddit r/ExperiencedDevs 2026 帖提问原文——6 年经验开发者坦承没读过 TPP/Code Complete/Clean Code，"Now the industry feels like it's changing faster than ever AI tools, new workflows... are these books still worth reading today, or do they feel outdated?"（评论区未加载，社区回答未获取）。
  6. 证据是否充分：对"改版改了什么"相当充分（两份 tips 清单 + 逐章对比书评三角验证）；对"仍然有效"的判断主要靠书评人自述与 HN 轶事（非系统性数据）；对"过时"判断里，被第二版自己改掉的部分证据硬，被社区指认过时但第二版仍保留的部分（如 blackboard）证据中等。

5. 结论

  1. 书的三层结构决定了"过时"的分布：哲学层（责任/能动性/学习/沟通/道德罗盘）几乎不会过时，且 2e 还在加强（Tip 3、Tip 98/99）；原则层（DRY/ETC/正交性/tracer bullets/小步/反馈）跨 27 年成立，但应用边界被修订（DRY 让步于合理复用、继承被降级）；技术层（编辑器选型、代码生成、黑板模式、并发具体技术）是最先腐烂的部分，2e 自己动刀换掉了大半。
  2. "仍然有效"的核心清单（按 2026 年实用度排序）：ETC 元判据 > DRY-as-knowledge + 正交性 > tracer bullets（端到端薄切片）> 小步+反馈 > 需求反馈循环 > 没有最终决定 > 测试是设计反馈（Tip 66/67）> 版本控制驱动一切（Tip 89）> 调试心态（Tip 29/33）> 道德罗盘（Tip 98/99）。
  3. "已过时"的核心清单：单一编辑器忠诚度（被 2e 反转）、代码生成 tip（被 2e 删除，但在 LLM 时代变相复活）、继承式复用（被 2e 反转）、DRY 绝对化（被 2e 收缩）、黑板模式（业界未采纳）、并发章的具体技术（书评人判过时）、以及所有绑定 1999 年工具链的示例。
  4. 对 2026 年读者的净判断：值得读，但读法比读不读更重要——(a) 直接读 2e，别读 1e（作者自己都不再推荐第一版，HN ralphc 转述 Changelog 352 期）；(b) 按需跳读而非通读（HN diminoten："The book isn't meant to be read front to back"）；(c) 资深者把它当"确认自己直觉的权威背书"价值大于"学新东西"（HN codesushi42 问答：commandlinefan 答"mostly just entertaining, well-written anecdotes - there's not really that much to learn there"——对老手成立）；(d) 早读收益最大（SloopJon 时机效应）。它比 Clean Code 经得起时间检验是社区主流比较结论（搜索级：qntm 文章也承认 TPP "is better"，本次未精读 qntm 原文）。
  5. 这本书教不了 2026 年的事：AI 辅助编程（官方页零提及，已核实）、云原生/平台工程、远程异步协作、供应链安全。这些缺口不是它的错——但意味着它不能再作为"唯一的工程观启蒙"。

6. 局限

  1. 未读全书：所有书籍内容均来自官方 tips 页、免费样章标题、以及三份书评/笔记的转述，未直接通读 20 周年版全书；逐章对比只有 dev.to 的前三章差异（作者自述只做了前三章）。
  2. 第一版 tips 清单为社区摘要（GitHub HugoMatilla 仓库），非出版方一手 PDF；Pearson 官方样章 PDF 已下载但本环境 PDF 页提取不可用，未能核验。"1e 无此条"的判断有个别条目可能是改写而非新增。
  3. 社区证据是轶事不是数据：HN 103 条评论与 Reddit 帖都是个人经验陈述，"仍然有效"的结论没有系统性研究支撑（软件工程建议的效果本就难量化——HN ilovecaching 正是用这一点攻击 Uncle Bob 和本书：_qualitative not quantitative_）。
  4. 几处标注为传闻/二手：作者不再推荐第一版（Changelog 352 期，未亲自听）；二十年不更新的法律原因（sramsay 自称 hearsay）；"约 1/3 主题全新"（搜索级）。Reddit 2026 帖只有提问没有回答。
  5. 时间偏差：HN 讨论发生在 2019 年 9 月（新书发布周），对 2e 本身的第一手读者反馈偏少；2026 年视角主要来自 Reddit 提问与我的综合推断，而非 2026 年的大量书评。
  6. 我未做的替代检验：无本地实证（本书为方法论主题，无代码可跑）；上述所有来源验证均为在线抓取完成于本次会话。

7. 对我的启发

  1. "过时"的正确姿势是"重审前提"而非"更新引用"。2e 的改版方法论（"we did both"）直接适用于我维护的任何长期资产——知识库、模板、agent 工作流：每隔几年应该问的不是"工具名换没换"，而是"当年这么设计的假设还成立吗"。我自己的笔记管线里，2e Tip 19 的 Neal Ford 引文（"Yesterday's Best Practice Becomes Tomorrow's Antipattern"）值得钉在显眼处。
  2. ETC（Easier to Change）是我目前见过的最短的好设计判据，可以直接用于 agent/提示词工程的架构决策：当两个方案难分高下，选"以后更容易改"的那个。曳光弹（Tip 20）+ 端到端构建（Tip 68 "Build End-To-End, Not Top-Down or Bottom Up"）+ 小步（Tip 42）组合起来，恰好就是搭 AI 工作流的最优实践：先打通一条最薄的端到端链路，再逐段加厚。
  3. Don't Outrun Your Headlights 与 agent 自主性：2e 的"只看清眼前的路就只走眼前的路"对小步原则的表述，与 2020s agent 设计里"限制规划视界、每步校验"完全同构——1999/2019 的书给 2026 的 agent 工程提供了词汇表。
  4. DRY-as-knowledge 对我的知识库是直接命令：matrix.csv 里每条结论应有唯一权威出处；笔记与 matrix 之间不应存在手抄副本（重复=知识层面的坏味道）。Tip 11（English is Just Another Programming Language）则把我的写作/笔记流程正式纳入代码化管理——模板化、可自动化、可 diff。
  5. 对"推荐经典书"这件事本身的警惕：SloopJon 的时机效应 + rubinelli 的常识化效应说明，向他人（包括未来的自己）推荐这本书时应附带"什么时候读、怎么读"——早读、跳读、读 2e。这也提醒我给夜读管线挑经典时，优先挑"哲学层"而非"技术层"密度高的书，前者腐烂慢一个数量级。
  6. 道德罗盘 Tips（98/99）在 AI 时代权重上升："First, Do No Harm — Failure is inevitable. Make sure no one will suffer because of it." 和 "Don't Enable Scumbags — Because you risk becoming one, too." 写于 LLM 之前，但几乎是针对滥用 AI 造谣、生成垃圾、刷量场景的预写判词。做 agent/自动化管线时这两条应该进 checklist。
  7. Write Code That Writes Code 的死而复生是"过时判断"的最佳案例：一条被 2e 删除的 1999 年建议，在 2026 年以"自然语言→代码"的形态回归——判断一条建议过时之前，值得先问"它要解决的问题消失了吗，还是换了形态"。

附：来源清单（含未精读项标注）

精读原文（本次会话抓取全文）：

仅提问原文（评论未加载）：

仅搜索摘要级（未精读原文，谨慎引用）：

← 资料库今日播报 →