KISS 是什么
KISS（Keep It Simple, Stupid，源自 Kelly Johnson 的设计军规）在软件里指：在满足需求的前提下选择可理解、少机制的方案。复杂度是成本，不是资历证明——每多一个活动部件，就多一个需要部署、监控与排查的东西。
基本信息
| 核心取向 | 可理解、可调试，活动部件尽量少 |
|---|---|
| 判断标准 | 新人上手这段代码需要多少心智负担 |
| 典型反例 | 为一个开关需求引入消息队列与五层抽象 |
| 与抽象的关系 | 抽象用来消除重复与隔离变化，不为展示技巧 |
| 成本特征 | 复杂度是当期支出，收益往往是假设的 |
典型使用场景
- 只有一种实现的场景不必引入插件机制
- 内部工具优先直白实现，把复杂度留给核心链路
- 需求尚未稳定的部分先写直白版本，变化出现再抽象
- 能用成熟组件就不自研框架
- 文档与配置项也要克制，减少需要记住的前提
复杂度该花在哪里
复杂度该花在哪里
# 复杂版：为一个开关需求引入消息队列、消费者与状态存储
# 简单版：直接更新数据库，同时写一条审计日志
# 判断依据：
# - 量级高、需要削峰或可回滚补偿 → 异步与补偿机制值得
# - 只是配置开关 → 直白实现即可，机制成本换不来收益简单与简陋的区别
| 维度 | 简单 | 简陋 |
|---|---|---|
| 需求覆盖 | 完整覆盖，且无多余机制 | 漏掉边界与异常 |
| 可维护性 | 读一遍就能懂 | 靠口头约定传递知识 |
| 扩展方式 | 变化出现时再抽象 | 提前堆砌未知用途的结构 |
KISS 不是拒绝抽象：重复代码与四处散落的硬编码同样是复杂度。它反对的是没有明确收益的结构，而不是所有结构。
以未来扩展为由提前复杂化：成本当期支出、收益未知，而等扩展真的到来时，当初的设计通常已经过时。