← 全部书单 / 软件工程

《程序员修炼之道》

《程序员修炼之道》封面
作者: 安德鲁·亨特、大卫·托马斯
出版社: 电子工业出版社
出版年: 2005-1
原作名: The Pragmatic Programmer
8.7
★★★★★
豆瓣评分 · 2,437 人评价
未标记阅读状态
程序员的内功心法:不只教写代码,更教怎么思考、怎么跟人打交道、怎么持续进步。

总体观点

1999 年,两位干了二十多年咨询的老手把踩过的坑写成这本书,副标题“从小工到专家”——讲程序员怎么从埋头写代码,成长为独当一面、让人放心的专家。

核心观点:写代码只是工作的一小部分,真正的本事是“注重实效”——做事前先想清楚为了解决什么问题,对变化开放,对手艺负责。几十条短小精悍的 Tip,条条能直接用。

它不讲某个语言框架,讲十年二十年不过时的东西:怎么跟需求方沟通、怎么写出好改的代码、怎么持续学习。DRY、破窗理论、曳光弹开发,最早都从这里流行起来。

核心观点

  1. 1. 别和破窗户住在一起(破窗理论)

    一栋楼有扇破窗长期没人修,会传递“没人管”的信号,很快更多窗被打破。代码一样:一个烂命名、一段复制粘贴没人管,其他人就觉得“这里可以随便写”,质量一路滑坡。看到破窗,顺手修好。

    接手老项目看到 data1、data2,想“算了能跑就行”,接着自己也随便命名,三个月后模块谁也看不懂。反过来顺手改成 userList,别人看到“这里有人在乎”,也会认真写。
  2. 2. 先打曳光弹,再全力开火

    别一上来憋大招写完整系统,先做能从头跑到尾的最小可用版本——界面能点、流程能走通,哪怕很糙。立刻知道架构对不对、需求理解偏没偏,偏了也只浪费几天。

    做在线点餐,先做只能“选菜→下单→看到订单”的简陋版给用户点一点。对方说“其实想要扫码点餐不是 App 点餐”,你只浪费一周,不是两个月。
  3. 3. 正交性:改A别影响B

    系统各部分尽量独立,改一个地方不牵一发而动全身。正交的系统好改好测 bug 少;耦合在一起的系统,改个按钮颜色都可能把支付搞挂。

    注册功能把校验手机号、发短信、写数据库全塞一个函数,改图形验证码时注册流程挂了。拆成三个独立模块,换验证码只动一个。
  4. 4. DRY:别重复自己

    每条知识、每份逻辑,系统里有且只有一个权威出处。重复代码是万恶之源——改的时候要改好几处,漏一处就是 bug。看到重复就抽出来。

    折扣逻辑在下单页和购物车页各写一遍,规则改成“满 200 减 20”,你只改了下单页,用户看到的价格和下单时不一样,客诉来了。抽成一个函数,两处都调它。
  5. 5. 死掉的程序不会说谎(早崩溃)

    程序出问题最可怕的不是崩溃,是“带病运行”——数据错了还假装没事往下走,最后错得离真相十万八千里。发现不对劲立刻停下报错,别硬撑。立刻崩溃的程序,至少诚实。

    函数要求传用户 ID,结果传进来是空。默默返回空结果,账单算错了都不知道;直接抛异常“用户 ID 不能为空”,bug 定位从三天变三分钟。
  6. 6. 把知识当投资组合来经营

    技术会贬值,今天热门的框架三年后可能没人用。像理财一样定期加仓:每年学一门新语言、每季度读一本技术书。目标不是追热点,是永远有学习新东西的能力。

    Java 程序员每年学点别的:今年学 Python 写脚本省下每周两小时,明年学 Go 理解并发。公司转技术栈时,别人慌,你上手快得多。
  7. 7. 先对橡皮鸭解释清楚

    调试卡住时,找个橡皮鸭,把代码一行行讲给它听,解释每行干什么、期望发生什么。很多时候讲到一半自己就发现 bug 了——“讲清楚”逼你把含糊的地方想明白。

    排序结果不对,对鸭子讲:“这里按年龄排序……等等,我传的真是年龄字段吗?哦,传的是字符串,‘10’排在‘9’前面了!”bug 找到,先改脑子。
  8. 8. 做需求的挖掘者,不做复述机

    用户说“要一匹更快的马”,复述机去造更快的马;挖掘者多问一句“你到底想解决什么”,发现他只是想“更快到达”,于是造出汽车。别当传声筒,像记者一样深挖到真正痛点。

    产品说“表格加个导出 Excel 按钮”,多问两句发现他只是每周一手动拷数据做周报。直接做“每周一自动发周报邮件”,连按钮都不用点。
树状思维导图

全书思维导图 · 知识脉络树

💡 拖拽平移 · 滚轮缩放 · 点击分支圆点折叠/展开
已复制思维导图大纲到剪贴板!

全书结构

  1. 第1章 注重实效的哲学

    承担个人责任并提供选择而非借口,警惕破窗效应及时修复代码缺陷,保持危机感与持续学习的敏锐。

    线上服务出现异常时主动在群内通报根因并给出降级与修复方案,而不是借口网络超时或前人遗留设计推脱责任。
  2. 第2章 注重实效的途径

    严守 DRY 原则消除重复知识,保持模块间的正交性以解耦变更,运用曳光弹开发打通端到端骨架。

    新系统研发第一周先用硬编码数据跑通从前端页面到数据库的端到端调用链路,验证全套技术栈连通性。
  3. 第3章 基本工具

    精通纯文本文件、掌握 Shell 命令行、精通主力编辑器并掌握版本控制,编写脚本自动化所有机械劳动。

    用一段十行的 Shell 脚本定时抓取、解压并过滤生产日志中的错误堆栈,两秒钟产出当日告警分析报告。
  4. 第4章 注重实效的偏执

    按契约设计(DBC),死程序不说谎——出现不可恢复错误时尽早崩溃,使用断言防范绝对不可能发生的情况。

    转账函数入口校验金额必须大于零且账户状态正常,如果不满足直接抛出不可恢复的运行时异常,严防错误数据下渗。
  5. 第5章 弯曲,或折断

    遵循迪米特法则隐藏内部结构,利用事件驱动与发布订阅实现时间解耦,利用元数据驱动代码动态行为。

    UI 组件不直接穿透对象层层调用底层数据的嵌套字段,而是通过监听事件总线消费状态,组件随时可自由替换。
  6. 第6章 当你编码时

    依靠深思熟虑而非巧合编程,把重构当作呼吸般的日常习惯,编写易于自测的无副作用代码。

    看到一段逻辑碰巧能跑但原理不明,绝不上线,而是查明并发竞态后补上清晰的同步锁与单元测试。
  7. 第7章 在项目开始之前

    需求是挖掘出来的而不是现成的,解开看似不可能的谜题,警惕过度形式化的规范,用科学估算指导规划。

    深入业务现场发现用户要求“复杂统计大盘”的真实目的是每天早上了解昨日营收,最终仅用一个钉钉机器人推送搞定。
  8. 第8章 注重实效的项目

    组建务实高效的敏捷团队,推行严格无情的全自动化构建与测试,早交付勤反馈,超越用户期望。

    每次提交代码自动触发 CI 跑完所有单元测试并在测试集群自动部署,使产品随时处于可向客户演示的可发布状态。
返回 软件工程 目录

观点与结构均为转述总结,非原文摘录。封面图片来自豆瓣读书,仅作展示。

豆瓣评分与评价人数为逐本人工核实当天的数值。 · GitHub 仓库 · v1.0.0