三条原则是什么
DRY 指知识的唯一来源，同一业务规则或常量只在一处表达；KISS 指优先选择简单方案，把复杂度用在真正需要的地方；YAGNI 指不实现当下不需要的能力，等真实需求出现再扩展。三条原则共同约束过度设计，常被误读为“禁止任何重复代码”“一切从简”与“拒绝所有扩展点”，实际它们针对的是同一件事：控制变化成本。
原则与误用
| 原则 | 含义 | 常见误用 |
|---|---|---|
| DRY | 同一知识只表达一次 | 为消除表面重复强行抽象出错误概念 |
| KISS | 简单方案优先 | 把简单问题包装成通用框架 |
| YAGNI | 只做当下需要的能力 | 拒绝必要的扩展点设计 |
| 共同目标 | 控制变化影响面与维护成本 | 拿原则当挡箭牌拒绝合理抽象 |
判断方法
- 两处代码长得像但变化原因不同，不应该合并（重复的偶然，不是重复的知识）
- 同一业务规则在多处出现且必须同时修改，属于真正的重复，应抽取
- 新增能力需要引入第三个抽象层，先确认是否已有两个真实实现
- 通用方案需要枚举未来所有场景，说明当前就应该先写具体实现
- 扩展点只在已知日期或路线图上出现时才预留，避免为想象留接口
- 重构时先补测试，再消除重复，避免合并过程中引入行为变化
基本信息
| 适用范围 | 代码、配置、文档、测试数据与业务流程 |
|---|---|
| 评判标准 | 改动一处业务规则需要修改几个地方，数量越少越好 |
| 常见反例 | 复制粘贴后分别改造，规则逐渐分化且无人察觉 |
| 常见过度 | 为三行相似代码建一套配置驱动的通用引擎 |
| 配合使用 | 与 SOLID 一起约束职责划分与抽象程度 |
DRY 的对象是知识而不是代码字符：两段代码形式相同但服务于不同业务规则，合并后一旦其中一方的规则变化，反而被迫增加分支。
以 YAGNI 为由完全不留扩展点，遇到真实变化时只能大规模修改，成本高于提前预留一个简单接口。