最近一次改代码，你画对象关系图了吗
回想最近一次觉得"这段代码改起来别扭"的经历。你有没有花十分钟画出涉及的类和它们之间的调用关系？
画了——你在做结构分析。没画——你在凭感觉重构。感觉有时候对，但无法积累成可复用的判断力。
你能说出变更方向吗
最近一个模块，你能用一句话说出它未来最可能的变更方向吗？"行为变体会增加""功能需要动态叠加""创建方式会变"——说得出来的，模式选择就有锚点。
说不出来也没关系。说不出来就暂时不引入模式，等真实变更发生了再决定。这比猜一个方向然后提前引入更安全。
你的抽象层数和变体数匹配吗
数一下：当前模块里有几层抽象（接口、抽象类、工厂）？有几个具体的变体实现？
抽象层数 ≤ 变体数量，通常没问题。抽象层数 > 变体数量，大概率过度设计了。三层工厂两种产品、四层装饰器三种功能——这种比例关系就是过度设计的定量信号。
新同事多久能读懂你的模块
假设一个有两三年经验的开发者加入你的团队。给他你最近重构过的那个模块，他需要多久能理解结构并开始改代码？
如果答案是半天以内——结构合理。如果答案超过两天，而业务逻辑本身并不复杂——结构可能过度了。设计模式的目的是让代码更容易被理解和修改，如果引入模式之后理解成本反而上升了，这个模式就没有达到目的。
去年有没有一层抽象从来没用到过
翻翻你项目里的接口和抽象类。有没有某个接口只有一个实现，而且过去一年没有加过第二个实现？
有的话，它是"以防万一"留的保险。但保险也有成本——每次阅读代码都要多跳一层。如果一年内都没用到，这层保险的预期收益已经很低了。考虑直接删掉，用具体类替代。等真的需要第二个实现的那天，再把接口加回来。IDE 的重构工具让这个操作几分钟就能完成。