反模式：从工程结果反推日常决策

这篇文章不追求“概念大全”，只聚焦 9 个最容易在日常开发里反复出现的反模式。它们的共同点是：当下看起来省事、稳妥、专业；长期却把系统推向更高的复杂度、更低的产出、更差的可维护性。

每一节都按同一模板组织：是什么 → 为什么糟糕 → 常见信号 → 应对做法。你可以把它当成日常 code review / 方案评审的检查清单。

1. 过早优化

是什么
在缺少真实数据（压测、线上监控、profile）之前，就针对“可能的瓶颈”做性能工程。

为什么糟糕

• 真正瓶颈往往和直觉不同，错误方向的优化只是在堆复杂度
• 为性能提前引入缓存、并发、异步、复杂算法，会带来隐蔽 bug 与可读性下降

常见信号

• 还没定位热点就先加缓存、先上队列、先分库分表
• 用未经验证的“启发式”替换成熟算法，只因为“理论上更快”
• 早期阶段就为极端高负载做过度架构，而系统大部分时间空闲

应对做法

• 把可读、可测、可运行的实现放第一位
• 性能问题按流程处理：测量 → 定位 → 设计实验 → 优化 → 回归验证
• 允许为增长做“可优化的设计”，但拒绝“先写复杂再说”

2. 单车车库（Bikeshedding）

是什么
团队在琐碎、主观、边际收益极低的问题上耗费大量讨论时间。

为什么糟糕

• 消耗注意力与会议带宽，挤占真正需要讨论的关键决策
• 让工程节奏被噪声牵着走，形成“讨论即产出”的幻觉

常见信号

• 对按钮位置、命名、缩进风格争论数小时甚至数天
• 在“封面配色”这类议题上需要投票、反复拉会

应对做法

• 识别到后立刻压缩决策成本：限定讨论时间、快速拍板（必要时投票/抛硬币）
• 对确实重要但主观的选择，用 A/B 或数据复盘替代无休止争论

3. 分析瘫痪

是什么
把“不确定”当成“继续分析”的理由，导致行动被无限推迟。

为什么糟糕

• 项目延误甚至停摆；等到要做时结论已经过时
• 没有新数据点的分析只会增加猜疑与分歧

常见信号

• 需求、UI、数据库设计讨论几个月/几年仍无法落地
• 每次卡住都说“再收集一点信息就能决定”

应对做法

• 用迭代推进：先做最小可验证方案，用反馈驱动下一轮
• 把“不确定”拆成可实验的问题：做原型、跑数据、做灰度

4. 上帝类

是什么
一个类控制过多对象、承担过多责任、拥有过多依赖，成为系统的“中心黑洞”。

为什么糟糕

• 违反单一职责：难测、难改、难定位问题
• 依赖爆炸导致改动扩散，维护成本随时间指数上升

常见信号

• 类名带 Manager / Controller / Engine / System 等泛化词
• import 过多、方法数量巨大、同时处理互不相关的业务

应对做法

• 拆分责任：把决策点、编排、领域逻辑、IO 边界分离
• 让每个小类具备清晰职责与可测试接口

5. 新增类恐惧症

是什么
把“类的数量”误当成“复杂度”，因此抗拒拆分与抽象。

为什么糟糕

• 大类把多种职责揉在一起，复杂度被隐藏并持续增长
• 维护者需要在脑中维持更多上下文，沟通与测试成本更高

常见信号

• “别拆了，类太多不好找”成为拒绝重构的默认理由
• 一个类为了“少建文件”而承载多条业务链路

应对做法

• 以职责边界决定拆分，而不是以“类数量”决定
• 允许类变多，但要求每个类更小、更聚焦、更易测试

6. 内部平台效应

是什么
在业务系统里重复发明操作系统/运行平台/语言已经提供的能力（调度、缓冲、队列、语法结构等）。

为什么糟糕

• 平台级能力难做对：易出现瓶颈、漏洞与边界缺陷，规模一大问题暴露
• 自造轮子降低可读性与工具生态适配性，增加新成员学习成本

常见信号

• 把数据库当工作队列用
• 自己实现磁盘/缓存/任务调度，而不是用成熟组件
• 因为不熟悉新语言/新平台，硬把旧语言的习惯“移植”过去

应对做法

• 先学习并用好平台提供的标准能力与成熟组件
• 只有在确有约束（性能、安全、隔离、合规）时才考虑定制实现

7. 魔法数和字符串

是什么
在代码里直接写未命名的数字/字符串字面量，让语义隐藏在常量值里。

为什么糟糕

• 阅读者无法从值本身理解含义，认知负担上升
• 重构时容易误替换，产生微妙 bug
• 字符串字面量会拖累国际化与统一文案治理

常见信号

• 600, 600、"point"、"OK"这类值在多处出现但语义不一致
• 修改一个值需要全局搜索替换并祈祷不误伤

应对做法

• 用命名常量/枚举/配置/资源文件表达含义
• 保留少量“约定俗成”的例外（如 0 下标、100 表示百分比），但要克制

8. 数字管理

是什么
把指标当成决策本身，而不是决策的输入：严格依赖数字做决定。

为什么糟糕

• 模型可能失效或过期，但数字仍在“看起来合理”地驱动错误动作
• 指标会被优化甚至被博弈，导致偏离真实目标
• 自动化决策一旦建立，错误会被规模化放大

常见信号

• 用代码行数、提交次数衡量产出
• 用“坐班时长”衡量贡献

应对做法

• 让数字服务于判断：用指标辅助决策，但保留对业务目标与上下文的校验
• 关键指标要定期复核有效性，避免指标漂移

9. 无用（幽灵）类

是什么
类本身没有真正责任，只是转发调用、改名包装、增加一层无意义抽象。

为什么糟糕

• 增加维护与测试成本，降低可读性
• 阅读者需要先理解“它为什么存在”，最终发现“它什么也没做”

常见信号

• 类的方法几乎都是一行：把调用转交给内部对象
• 包装层只做“换名字”，并没有提供一致的抽象或额外约束

应对做法

• 删除或内联这层抽象，直到每个类都有明确责任
• 如果确实需要封装，确保它提供真实价值：边界隔离、策略组合、约束校验、领域语义等

结语：用反模式做日常检查

如果要把这 9 条浓缩成一句话：先用最小复杂度解决真实问题，再用数据与反馈驱动演进。
在方案评审与 code review 时，优先检查：是否在缺少数据时提前复杂化、是否把注意力花在低价值议题、是否用抽象掩盖了职责边界。*** End Patch