做后端久了，我对“方案简单”的理解逐渐从代码少，变成了别人接手时能看懂、上线时能操作、出问题时能定位。KISS 原则提醒我们：在满足实际需求的前提下，尽量避免不必要的复杂度。
KISS 常被展开为 “Keep It Simple, Stupid”，也有强调清晰直白的表达。这里关注它在软件设计中的用法，不把它当成省掉必要机制的理由。
一、简单应该从整个流程衡量
假设后台需要每天生成一份报表。数据量不大，现有数据库可以完成查询，业务也允许第二天查看结果，那么一个定时任务、明确的输出位置和失败告警，可能已经足够。
如果此时引入多套消息队列、分布式编排和通用任务平台，开发出的组件可能更丰富，但团队也需要承担部署、权限、重试、版本和故障定位的成本。没有相应需求时，这些成本很难得到回报。
反过来，若报表有严格时限、任务相互依赖、单次失败会影响结算，那么重试、幂等、监控和审计就可能是必要部分。删掉它们，只是把复杂问题留给了值班的人。
二、把混乱变成清楚的约定
管理中“把复杂问题简单化、把混乱事情规范化”的思路，也适合工程协作：
| 容易增加理解成本的做法 | 可以考虑的改进 |
|---|---|
| 同一个状态在不同接口中使用不同名称 | 统一状态定义与转换规则 |
| 配置散落在代码、文档和机器中 | 明确配置入口、默认值和覆盖顺序 |
| 每次发版依赖某个人记住手工步骤 | 用可检查的脚本和短文档固定流程 |
| 多种错误都返回空值 | 定义能区分失败原因的错误处理方式 |
规范化的目标是减少猜测，不是让每个小功能都多填几张表。需要保留的约定，应当能帮助后来的维护者做出正确操作。
三、几种常见误用
- 简单等于代码最短。 把验证、查询和副作用挤在一行，往往增加阅读成本。
- 简单等于不分模块。 职责清楚的边界能降低理解范围，不必要的抽象才是负担。
- 简单等于永远不用新组件。 新组件能明确降低现有复杂度时，同样可以符合 KISS。
- 简单等于跳过错误处理。 正常路径短了，故障恢复却可能更困难。
四、评审时我会问的几个问题
先确认当前需求、数据规模和可靠性目标，再比较可行方案。这个组件解决了哪个已经存在的问题？同事能否用几句话解释完整的数据流？失败后怎么发现、重试和恢复？去掉一层抽象后，职责会更清楚还是更混乱？
这些问题比“用了多少技术”更有助于选择方案。先把当前问题解决清楚，保留合理的演进空间，再由真实需求推动下一步设计。
相关笔记：系统设计。
