阅读笔记2《程序员修炼之道--从小工到专家》

第四第五章讲的是偏执与韧性。
一、向内的偏执：对自己也要保持怀疑：
第四章标题中的“偏执”并非贬义，而是一种职业级的清醒。作者开篇借用车险心态——每个人都觉得只有自己是好司机，别人都不会开车——点破真相：注重实效的程序员更进一步，他们连自己也不信任-4。
这一章的核心是防御性编程，但作者的洞察不止于“检查参数”“处理异常”。更深层的启示在于：承认自己无法写出完美代码，反而是一种解放。正是因为知道错误不可避免，才需要系统性地设防。
按合约设计（DBC） 是本部分最亮眼的方法论。它把软件模块的交互类比为商业契约：前条件、后条件、类不变项——双方明确权利与责任，出了问题按合同追责-1-4。这不是增加负担，而是将隐形的“默契”显性化。我由此反思：过去那些因“调用者应该传对参数”而省略的校验，本质上是对责任的模糊化。
死程序不说谎是极具冲击力的原则。作者直言：要崩溃，不要破坏-4。一个勉强运行的病态程序，比立即死掉的程序更危险——它会污染数据、掩盖真相、耗尽排查者的时间-6。这让我重新理解了“健壮性”：不是永不倒下，而是倒下时不拖累战场。
断言式编程则是自我质疑的技术化。作者说，每当你冒出“那当然不可能发生”的念头——这正是该加断言的地方-4。那些被我们视为“太基础、无需检查”的假设，往往是事故的源头。
二、向外的韧性：为变化而设计：
如果说第四章是“防守”，第五章就是“柔术”。“弯曲，或折断”——要么学会适应，要么断裂-3。技术世界没有永恒的正确答案，只有不断漂移的需求和约束。
解耦与得墨忒耳法则是本章的实践抓手。作者借一句谚语点题：“好篱笆促成好邻居”-1。模块之间不应过分亲密，一个对象只应与其直接朋友交谈，不向陌生人问路-9。这个简单的约束能防止代码陷入“火车失事”式的链式调用。我意识到：耦合往往是“方便”的代价——一次省略封装、一次直接访问，都在积累技术债。
元程序设计的理念在今天读来仍有预言性：将抽象放进代码，将细节放进元数据-1。让系统“软”下来——数据库连接、业务规则、甚至工作流，都应可配置而非硬编码。这不是过度设计，而是承认唯一不变的是变化本身。
时间耦合是本书最具原创性的洞察之一。时间不仅是性能维度，更是架构维度。并发（同时发生）与次序（先后依赖）是两个独立的约束-1-2。如果我们默认一切操作都是顺序的，就等于主动放弃了并行化的可能性。解时间之耦，本质是不把“碰巧的顺序”误认为“必然的逻辑”。
黑板系统作为解耦的终极形态，让模块像专家围绕黑板一样协作——匿名、异步、彼此不知，却共同求解问题-1。这在当时是超前架构，如今在事件驱动、数据流系统中已成为常态。
总而言之，偏执是向内，韧性是向外，前者承认“我会犯错”，后者承认“世界会变”。这不是悲观的宿命论，而是务实的清醒。