《程序员修炼之道:从小工到专家》

The Pragmatic Programmer, Andrew Hunt & David Thomas(中文版,电子工业出版社)。原著 1999 年出版,被誉为”程序员必读经典”,与《代码大全》《重构》并列。中文版 355 页。

核心命题

编程不是”敲入某种编程语言的语句”,而是一种需要用心学习的技艺——如同木工、音乐创作、驾驶飞机,既需天赋,更需坚持不懈的学习和训练。全书围绕”注重实效(Pragmatic)“展开:对职业生涯负责、诚实面对无知与错误、持续投资知识资产。

全书结构(46 条贴士,8 章)

  • 第1章 注重实效的哲学(贴士1-6):我的源码让猫给吃了、软件的熵、石头汤与煮青蛙、足够好的软件、你的知识资产、交流
  • 第2章 注重实效的途径(贴士7-13):重复的危害(DRY)、正交性、可撤销性、曳光弹、原型与便笺、领域语言、估算
  • 第3章 基本工具(贴士14-20):纯文本的威力、shell游戏、强力编辑、源码控制、调试、文本操纵、代码生成器
  • 第4章 注重实效的偏执(贴士21-25):按合约设计、死程序不说谎、断言式编程、何时使用异常、怎样配平资源
  • 第5章 弯曲,或折断(贴士26-30):解耦与得墨忒耳法则、元程序设计、时间耦合、它只是视图、黑板
  • 第6章 当你编码时(贴士31-35):靠巧合编程、算法速率、重构、易于测试的代码、邪恶的向导
  • 第7章 在项目开始之前(贴士36-40):需求之坑、解开不可能解开的谜题、等你准备好、规范陷阱、圆圈与箭头
  • 第8章 注重实效的项目(贴士41-46):注重实效的团队、无处不在的自动化、无情的测试、全部是写、极大的期望、傲慢与偏见

重点贴士摘录(原文 OCR 采样)

贴士1:我的源码让猫给吃了——为自己的行为负责

“在所有弱点中,最大的弱点就是害怕暴露弱点。” 责任是你主动担负的东西;对于不可能做到或风险太大的事情,你有权不去为之负责。但一旦承诺,就切实负起责任——犯错时诚实承认,设法给出各种选择,不责备别人或拼凑借口,不把问题归咎于供应商、编程语言、管理部门或同事。

贴士2:软件的熵——破窗户理论

“不要在’破窗户’(设计低劣的代码、糟糕的管理决策)未修复的情况下继续开发。发现破窗户而不修,团队会想’其余代码也是垃圾,我照着做就行’,项目随即衰败。” 反过来,如果代码整洁优雅,即使最后期限如火咆哮,也没人想成为第一个弄脏它的人。

贴士5:你的知识资产

“知识上的投资总能得到最好的回报”(富兰克林)。知识和经验是最重要的职业财富,但它们是有时效的资产(expiring asset)——新技术出现后你的知识会过时,你的价值也随之降低。对策像管理金融投资组合一样管理知识:定期投资、多元化、低买高卖(趁新技術还冷门时学习)、复盘再平衡。

贴士7:重复的危害(DRY)

系统中的每一项知识都必须具有单一、无歧义、权威的表示(DRY - Don’t Repeat Yourself)。程序员收集、组织、维护和利用知识,而知识不断变化——维护不是发布后才开始的修 bug,而是整个开发过程中的例行事务。

贴士8:正交性

正交 = 一个事物变化不影响其他事物(源自几何学)。设计良好的系统中,数据库代码与用户界面正交:改界面不影响数据库,换数据库不用改界面。维持正交性的方法:设计独立良好定义的组件、代码保持解耦、避免全局数据、重构相似的函数。对照”直升机”类比:非正交系统的控制器互相牵连,动一个引发全部连锁反应。

贴士10:曳光弹

“预备、开火、瞄准……” 面对全新项目(需求含糊、技术不熟、环境会变),不要预先做一次大计算然后射击(瀑布式文档定死一切),而要用曳光弹:构建一个端到端可运行的薄骨架,在真实环境里即时获得反馈,逐步逼近目标。曳光弹贵在反馈即时、且与”真弹药”在同一环境下发射。

贴士21:按合约设计(DBC)

Bertrand Meyer 为 Eiffel 语言发展的概念:用文档记载(并约定)软件模块的权利与责任。合约规定你的权利与责任、对方的权利与责任、以及任何一方违约的后果。正确的程序 = 不多不少、恰好做它声明要做的事情的程序。

贴士22:死程序不说谎

“所有的错误都能为你提供信息。” 别陷入”它不可能发生”的心态——每个 case/switch 都要有 default 分支,就是为了知道何时发生了”不可能”的事情。尽早检测问题,必要时早崩溃(Crash Early)——死程序的危害通常比带病运行的程序小得多。

贴士31:靠巧合编程

老电影里的士兵用刺刀试探雷区,试探几步没爆炸就以为是安全的,直起身正步前进——被炸成碎片。靠运气和偶然的成功编程,结论是致命的。 要深思熟虑地编程:审视周遭情况、检查潜在问题、不在意外发生时处于不利位置。

贴士33:重构——软件更像园艺而非建筑

建筑比喻(画蓝图→施工→入住维修)误导了软件业。软件更像园艺:按计划种植,有机生长,有些成长有些淘汰,随时调整布局、分株修剪、拔除杂草。早重构、常重构,像在花园里除草一样,铲除问题的根源。

贴士43:无情的测试

“Test Early, Test Often, Test Automatically——早测试,常测试,自动测试。” 找 bug 像用网捕鱼:小网(单元测试)捕小鱼,大网(集成测试)捕鲨鱼,发现漏洞就补。使用自动测试的团队成功机会远大于搁在架子上的测试计划。“测试你的软件,否则你的用户就得测试。“

快速参考指南(70 条核心原则,附原书页码)

精选关键条目(完整清单见书末”快速参考指南”):

  1. 关心你的技艺(Care About Your Craft)
  2. 思考你的思想(Think! About Your Work)
  3. 提供各种选择,不要找借口
  4. 不要忍受破窗户
  5. 做变化的推动者
  6. 记住大局
  7. 纯文本不会过时(Keep Knowledge in Plain Text)
  8. 用好一种编辑器
  9. 源码控制是工作的时间机器(Always Use Source Code Control)
  10. 要修正问题,而不是发出指责
  11. “Select”没有问题——bug 很可能在你的应用里,而不是 OS/编译器
  12. 不要假定,要证明
  13. 你不可能写出完美的软件
  14. 用断言避免不可能发生的事情
  15. 将异常用于异常的问题
  16. 要有始有终——分配资源的例程也负责解除分配
  17. 使模块之间的耦合减至最少
  18. 将抽象放进代码,细节放进元数据
  19. 总是为并发进行设计
  20. 不要靠巧合编程
  21. 早重构,常重构
  22. 测试你的软件,否则你的用户就得测试
  23. 与用户一同工作,以像用户一样思考
  24. 抽象比细节活得更长久
  25. 不要做形式方法的奴隶
  26. 昂贵的工具不一定能制作出更好的设计
  27. 时测试,常测试,自动测试
  28. 一个 bug 只抓一次(此后自动测试兜底)
  29. 像编写代码一样编写文档(英语就是一种编程语言)
  30. 把文档建在里面,不要拴在外面
  31. 温和地超出用户的期望
  32. 在你的作品上签名(Sign Your Work)

可行动点

  • 知识资产:每年学一门新语言(书荐:CLOS、Dylan、Eiffel、Objective-C、Prolog、Smalltalk)、每月读一本技术书、参与本地用户组/技术社区
  • WISDOM 离合诗(交流六问):你想让他们学到什么?他们感兴趣的是什么?他们有多富有经验?想要多少细节?谁拥有这些信息?如何促使他们听你说?
  • 立即引入:源码控制一切(不只是代码)、用断言保护假定、每个 switch 有 default、bug 只抓一次
  • 找出身边项目的两三处”破窗户”,与同事讨论怎么修

知识关联

  • SICP —— 同为程序设计哲学经典,SICP 偏抽象建构,本书偏工程实践
  • 与《重构》(Martin Fowler,同目录下有《重构-改善既有代码的设计 中文版.pdf》)互补:本书贴士33是重构的入门论证,Fowler 书是操作手册
  • DBC、断言、早崩溃 → 后续可关联防御式编程相关笔记
  • ThoughtWorks 文集(云盘 /books/ 下 thoughtworks 系列)延续本书的工匠精神传统

处理说明

  • 原书为扫描版 PDF(无文字层),全书 355 页;采用采样 OCR(tesseract chi_sim,24 页:前言3页 + 12个标志贴士页 + 快速参考指南10页)+ PDF 内嵌目录整理成本笔记
  • OCR 文本存在识别噪声,引用段落已人工校读;快速参考指南条目编号因 OCR 缺失部分为按原书内容推断,待确认
  • 本次未 OCR 全书正文;如需某章详细笔记可后续按需补做