客户催交付，我第一反应却是再买一套工具

上周四晚上十点，我在杭州的咖啡店给客户改一个小功能。对方问能不能第二天上线，我嘴上答应，手却先去翻新的协作工具。后来我才发现，真正拖慢我的不是工具，而是连一个小需求都改了三轮。我也卡过：忙起来总想靠新工具救场，结果只是把不会的东西藏得更深。

这五本书，究竟在解决什么

2008 年，Michael A. Foerster 在他位于美国威斯康星州的博客里列了五本值得记住的编程书。它们不是速查表，更像五位随时能请来的“同伴”：帮你理解代码、测试、维护和协作。老一辈开发者靠它们补基本功，今天的独立开发者也可以用它们减少返工。比如自由开发者林悦在上海接网站改版时，就用《代码大全》检查交接清单，避免把模糊需求直接写进功能里。

今天复刻，成本比想象中小

我算了一下：二手书大约 100 元，电子版通常 30—80 元；每天 30 分钟，选一本读完核心章节，大约 2 周。技术门槛是：会按目录找内容、能跟着书里的例子敲一遍，不需要懂复杂代码。第一步不是开软件，而是打开你最常拖延的旧项目，写下最近一次返工的原因，再翻目录找对应章节。先读摘要和目录也可以；这工具不是所有人都需要，现在不试也没事。

按你的阶段，我会这样安排

如果你刚起步，我会先读一本讲测试的书，拿自己的小项目做一张“交付前检查表”；如果你已经有 1—2 个客户，我会选讲维护和代码整洁的那本，把重复修改改成固定清单；如果正在扩规模，我会优先读讲团队协作的书，再让成员共同整理流程。我还在实践这套顺序：与其再买一个看起来更快的工具，不如先把团队已经承诺过的事情做稳。你可以先挑最近一次返工，只读与它有关的一章，再决定要不要继续。