可维护代码的两个反复追问："他离职了怎么办？""他没这么做怎么办？"

相比可读性和可发布性，”可维护的代码”这个评价维度天然更模糊，因为它要对应的是尚未发生的未来情况——新人往往很难想象现在的某个具体做法，会在未来对项目造成什么样的影响。给出的实用经验是：不需要试图预判所有未来场景，只要针对一段代码反复追问两个问题就够用了：一是”他离职了怎么办？”——这段代码的正确运转、这段逻辑背后的隐含约定和设计意图，有没有依赖某个特定的人才能理解和维护，一旦这个人离开团队，剩下的人能不能顺利接手；二是”他没这么做怎么办？”——这段代码是不是依赖某个隐含的、没有被显式检查或强制的前提条件才能正常工作，一旦有人（不管是无意还是故意）没有遵守这个隐含前提，系统会不会出问题、出问题之后能不能被及时发现。这两个问题看似简单，却能穿透很多可维护性问题的表象直击本质：模块内高度重复的代码、七拐八绕堆砌在一个巨大文件里的逻辑、依赖某个人脑子里才知道的隐含约定，这些问题的共同后果都是”一旦这个知道内情的人不在了，或者有人不小心破坏了这个隐含前提，系统就会陷入难以理解、难以修复的境地”。这个案例给出了一条评价”看不见摸不着的未来风险”的实用方法论：面对天然模糊、难以量化的评价维度，与其试图穷举所有可能出问题的具体场景，不如提炼出少数几个具有高度概括力的追问句式，反复用这几个追问去检验具体的代码和设计决策——这类追问句式的价值在于它们几乎能穿透绝大多数可维护性问题的表层，直接指向”这段代码对特定的人或特定的隐含前提有多大的脆弱依赖”这个核心风险。