第一次读这本书是两年前，当时觉得它讲的都是常识：写测试、重构、保持整洁。这次工作两年后再读，才发现常识背后是极高的纪律性要求——知道和做到之间隔着无数次项目的锤炼。

最有共鸣的三个观点

  • 「赶上进度」的唯一方式是把代码写好：返工才是进度最大的敌人，走捷径最终都会连本带利地还回去。
  • 专业主义意味着说「不」：承诺要有成本估算支撑，模糊的「我尽力」其实是对团队的失职。
  • 测试是设计工具：先写测试会倒逼代码可测试，而可测试性几乎等价于好的解耦。

联系到自己的实践

最近在项目中做缓存改造，我刻意践行了书中「红灯-绿灯-重构」的节奏：先写一致性 failing test，再实现延迟双删，最后把重复代码收敛成模板方法。整个过程下来，联调时间比预估少了一半。

「代码 review 时，你 评论 的不是同事的代码，而是团队的未来。」——整洁不是审美偏好，是团队协作的通信协议。

如果说有什么遗憾，是书中的例子都偏小而集中，真实业务系统的复杂度要高出几个量级。但这恰恰说明：把小事做到位的纪律，正是应对大规模复杂度的唯一基础。