anti-patterns

应拒绝的 SDLC 反模式

参考目录。在阻止提案时引用反模式名称，为用户提供清晰的词汇来讨论问题。

架构反模式

A-1. 上帝服务

迹象： 一个服务负责身份验证、计费、搜索、文件存储和电子邮件。 为何有害： 单一部署单元、单点故障、每个团队都要改动它，变更速度会随着时间推移而下降。 改进： 按业务能力拆分（DDD 限界上下文）。

A-2. 分布式单体

迹象： 有 12 个微服务，但它们共用一个数据库，而且一起部署。 为何有害： 承担了分布式系统的所有成本（延迟、最终一致性、运维开销），却没有任何好处（独立部署、隔离）。 改进： 要么真正分离（各自拥有数据库和部署流水线），要么合并。

A-3. 同步调用链

迹象： 请求 → 服务 A → 服务 B → 服务 C → 服务 D。 为何有害： 故障概率叠加，p99 延迟也会累积。 改进： 使用事件进行异步处理，或将热路径部署在一起。

A-4. 过早优化

迹象： 在迎来第一个付费用户之前，就编写自定义 Redis Lua 脚本、手动调优二进制协议。 为何有害： 先付出复杂性成本，却永远无法收回。 改进： 从简单方案开始。有负载数据后再优化。

A-5. 履历驱动开发

迹象： “我们来用 Kubernetes / GraphQL / 事件溯源 / DDD 吧”，但没有要解决的实际问题。 为何有害： 优化的是工程师的履历，而不是用户的成果。 改进： 问问“能解决问题的最简单方案是什么？”

计划 / 流程反模式

P-1. 一次性大规模重写

迹象： “我们用 <新框架> 重写吧。” 为何有害： 80% 的重写都会失败。旧系统凝结了多年来的错误修复。 改进： 采用绞杀榕模式。在新代码中实现新行为，让新旧代码共存，等流量迁移后再删除旧代码。

P-2. 英雄文化

迹象： “资深工程师 X 总是在凌晨 3 点修复故障。” 为何有害： 关键人员依赖度为 1。X 会精疲力竭，知识也无法传递。 改进： 编写运行手册、进行事后复盘、轮换值班、结对调试。

P-3. 没有可逆性计划

迹象： 计划包含无法回退的改动（数据迁移、公共 API 变更、破坏契约的版本发布）。 为何有害： 如果判断有误，恢复需要几天或几周。 改进： 批准前必须进行演练并制定回滚方案。

P-4. 计划没有时间限制

迹象： 任务名为“实现功能 X”，却没有完成标准。 为何有害： 范围没有边界，耗时会不断膨胀。 改进： 每项任务不超过 4 小时，并明确规定“完成 = X”。

代码级反模式

C-1. 上帝类 / 上帝函数

迹象： 一个类超过 500 行，或一个函数超过 100 行，而且要做 5 件无关的事。 为何有害： 测试会变成集成测试，差异内容也变得难以阅读。 改进： 遵循单一职责原则，提取协作者。

C-2. 字符串类型化

迹象： 状态以字符串（“open”“closed”“blocked”）传递，没有枚举。 为何有害： 拼写错误也能通过编译；新增状态时可能忘记更新 switch。 改进： 使用枚举 / 判别联合 / 品牌类型。

C-3. 捕获后继续

迹象：

try { doThing(); } catch (e) { console.log(e); }

为何有害： 隐藏错误，导致静默数据损坏。 改进： 只捕获能够处理的异常；其余异常重新抛出；记录包含上下文的信息。

C-4. 硬编码密钥

迹象： 将 API 密钥、密码、数据库 URL 放在源代码中。 为何有害： 它们会永远留在 Git 历史记录中；轮换密钥需要强制推送（这是不可能的）。 改进： 使用环境变量或密钥管理器。添加提交前钩子，搜索 sk-、ghp_ 等内容。

UI 反模式

摘自 Google AI Studio 关于润色生成式界面的指南（2026-09-16）： 识别这类问题最快的方法，就是看那些毫无意义的装饰。

U-1. 毫无意义的标签

迹象： 没有任何状态驱动的状态胶囊、徽章、计数器和标签——例如，在没有任何新内容、测试版内容或计数对象的界面上显示“新”“测试版”“AI”“3 条见解”。 为何有害： 读者无法分辨信号和装饰，因此会忽略使用相同视觉语言呈现的真正警告。这是识别生成式 UI 最可靠的标志。 改进： 每个标签都要说明其含义及背后的状态，否则就移除。

U-2. 占位图片

气味： 灰色方框、Lorem 图片，以及构建中损坏或从外部链接的图库图片 URL，而该构建本应展示给用户。 为什么不好： 第一印象会让人觉得产品尚未完成；外链资源可能会在不通知的情况下失效或更改，而且可能未经授权。 修复： 每张图片都有明确来源——为该产品生成、自有或已获授权，并从产品自身的资源中提供。

事故 / 运维反模式

O-1. 没有 SLO

气味：“今天生产环境好像很慢”，但没有 SLO 目标。 为什么不好： 无法判断这是违反目标还是正常情况。 修复： 设定 p99 延迟、错误率和可用性 SLO，并跟踪消耗情况。

O-2. 告警轰炸

气味： 每个错误都会触发寻呼。工程师不再查看告警。 为什么不好： 真正的事故会淹没在噪声中。 修复： 只有面向用户的故障才触发寻呼。其他信号放到仪表板中，而不是寻呼系统。

O-3. 事后复盘归咎于人

气味：“工程师 X 未经测试就部署了。” 为什么不好： 会抑制之后的事后复盘。归咎于人无法修复系统。 修复： 开展无责事后复盘。重点关注缺失的防护措施，而非个人。

O-4. 雪花服务器

气味：“别重启 SRV-PROD-3，它有一项未纳入 IaC 的特殊配置。” 为什么不好： 无法进行灾难恢复。 修复： 所有内容都纳入 IaC。服务器是牲畜，不是宠物。

如何使用此目录

在提案 / 评审中发现这些问题时：

1. 引用代码（A-3、P-1 等），让用户有统一的术语
2. 引用提案中的具体气味
3. 提出具体的修复方案
4. 如果用户不同意，将其记录为 ADR，并填写备选方案部分

何时不适用

• 业余项目、学习练习——反模式针对的是规模化场景
• 明确包含 // TODO delete in 2 weeks 的一次性代码
• 限时 POC，目标是“验证 API 是否确实可用”