内容摘要：《代码大全》我翻过三遍。第一遍在大学图书馆，硬着头皮啃了两个月，合上书只记得“变量命名要清晰”。第二遍在工作第三年，突然发现里面讲的防御式编程、子程序边界，全是踩过的坑。第三遍是去年，带新人时又翻出来

《代码大全》我翻过三遍。程序第一遍在大学图书馆，员书硬着头皮啃了两个月，程序合上书只记得“变量命名要清晰”。员书第二遍在工作第三年，程序突然发现里面讲的员书防御式编程、子程序边界，程序全是员书踩过的坑。第三遍是程序去年，带新人时又翻出来，员书看到“问题定义”那章，程序才意识到以前写代码慢，员书根子不在手速，程序在于没想清楚要解决什么。员书

这本书不适合当小说读。程序它像一本字典，遇到具体问题去查对应章节，效果最好。我见过有人从第一页读到最后一页，读完就忘了。别这么干。

《重构》和《代码整洁之道》经常被放在一起说。我的建议是：先读《重构》，再读《代码整洁之道》。前者教你识别坏味道，后者告诉你什么是好代码。顺序反了容易变成形式主义者——满脑子函数不超过二十行，结果把一个简单的循环拆成五个函数，调用链深得没法调试。Martin Fowler在《重构》里反复强调一点：重构的前提是有测试。没测试的重构叫赌博。我见过一个团队花两周重构核心模块，上线后订单丢失率涨了三个百分点，回滚又花了一天。后来查出来是某个边界条件在重构时被“优化”掉了。

《深入理解计算机系统》这本书，别名CSAPP。我第一份工作做嵌入式，同事推荐我读。读前六章就够了，后面几章偏操作系统和网络，除非你专门做底层。这本书最大的价值是让你明白：你写的每一行C代码，在机器层面发生了什么。缓存命中率、内存对齐、指令流水线——这些词听着远，但当你发现一个数组遍历顺序换一下，性能差三倍的时候，就明白为什么了。

《算法导论》我买了，没读完。实话。它更像参考书，不是学习路径。想学算法，先刷LeetCode前两百题，遇到不会的再去翻对应章节。直接啃书容易陷入数学证明的泥潭，忘了写代码才是目的。我认识一个算法很强的同事，他的方法很土：每道题先用最笨的办法写出来，能跑通，再想优化。他说“先让代码跑起来，再让它跑得快”。这话比任何算法书的前言都管用。

《人月神话》值得每个带过项目的人读。Brooks讲“向进度落后的项目增加人手，只会让进度更落后”，我第一次读到觉得反直觉，后来自己带项目才明白：沟通成本随人数平方增长。三个人干一个月的活，五个人干不一定半个月完成，可能一个月都干不完，因为要开会、对齐、写接口文档、处理合并冲突。这本书1975年出版，里面的道理到现在没变过。

《程序员修炼之道》适合工作一两年的人读。它不讲具体技术，讲的是习惯：DRY原则、正交性、 tracer bullet开发。我印象最深的是“不要留着破窗户”——代码里有一个烂函数不修，很快整个模块都会烂掉。这不是道德说教，是心理暗示。人看到别人乱扔垃圾，自己也会扔。

书单不用太长。五本左右，反复读，比读五十本只读一遍强。我自己的书架上，技术书不超过二十本，其中一半是工具书，遇到问题才翻。真正从头到尾读过的，也就七八本。剩下的时间，我选择读代码——读开源项目的源码，读同事的代码，读自己半年前写的代码。读自己旧代码最痛苦，也最有用，你会清楚地看到自己哪里进步了，哪里还在犯同样的错。

别把读书当任务。今天想学并发，找本《Java并发编程实战》翻两章；明天要写SQL，把《SQL必知必会》放桌上。带着问题读，读完就用，用了再回头读。这个循环比任何“必读书单”都管用。