"假设"与缺少抽象：最隐蔽、最难自我察觉的烂代码反模式

相比”意义不明”“表达能力差”“不恰当的组织”这几类比较容易被一眼识别的烂代码，”假设和缺少抽象”这种反模式出现得更频繁、表现形式更多样，也更难被制造它的程序员自己意识到问题。典型的演化路径是：最初写代码时对某个条件（比如文件路径）做了一个简单假设，后来这个假设不成立了（比如需要加载的内容变得更丰富），于是在原有代码基础上打补丁式地改动，之后需求又变了，再打一次补丁——代码在这种”假设-打补丁-再假设-再打补丁”的循环里越滚越复杂，却从未真正被重新抽象设计过。这类反模式的制造者往往是团队里开发效率看起来很高的人，他们的口头禅通常是”我每天要做XX个需求”或者”先做完需求再考虑其他的吧”——正是因为长期专注在快速交付具体需求上，没有余力停下来做多余的抽象思考，才不断在已有代码基础上叠加针对具体场景的特殊逻辑。这种模式最终导致的后果是代码变得极难复用：写代码时来不及考虑复用，代码难复用又导致下一个类似需求还要继续写大量新代码而不是复用已有逻辑，这本身形成了一个自我强化的恶性循环，一点点积累下来的代码带来组织和风格上的一致性问题，最终演变成一个”新功能基本靠复制粘贴”的遗留系统。这个案例给出的重要警示是：最危险的代码质量问题，往往不是那些一眼就能看出很糟糕的代码（意义不明、写法混乱），而是那些每一次单独看都”合情合理”（只是针对当前需求做了一个局部调整）、却在持续累积中悄悄让整体架构失去弹性的代码——这类问题因为每一步的改动都显得微小而正当，制造者本人也最难察觉自己正在制造一个长期的技术债务。