复杂性（Complexity）：
与理解系统如何工作相关的任何事物

复杂性不是代码行数，不是功能数量。
复杂性是"理解这段代码需要多少知识"。

复杂性 = 所需知识 / 产生的价值

好的设计：用最少的知识产生最大的价值

1. 变更放大（Change Amplification）
   - 一个看似简单的变更需要修改很多地方
   - 例：修改一个配置需要改10个文件
   - 例：添加一个字段需要改20个方法

2. 认知负荷（Cognitive Load）
   - 理解代码需要知道太多信息
   - 例：一个方法有20个参数
   - 例：一个类有50个公共方法

3. 未知未知（Unknown Unknowns）
   - 不知道需要知道什么才能安全修改
   - 例：修改一行代码导致意想不到的副作用
   - 例：删除一个"没用"的变量导致系统崩溃

最危险的是未知未知——你甚至不知道你不知道什么。

复杂性的信号：

1. 难以理解
   - 读代码时需要反复查看其他文件
   - 需要知道很多上下文才能理解一行代码

2. 难以修改
   - 一个简单功能需要改很多文件
   - 修改后需要运行很多测试

3. 难以测试
   - 需要 mock 很多依赖
   - 测试用例复杂且脆弱

4. 频繁出 bug
   - 修改总是引入新问题
   - 修复一个 bug 引入另一个 bug

简单 ≠ 容易
简单 = 没有不必要的复杂性

简单设计的特征：
1. 容易理解
   - 不需要太多背景知识
   - 代码自解释

2. 容易修改
   - 变更局部化
   - 影响范围可预测

3. 容易测试
   - 依赖少
   - 行为可预测

Ousterhout 的核心观点：
"简单是终极的复杂" —— 达芬奇
"让事情尽可能简单，但不能更简单" —— 爱因斯坦

// 变更放大的例子
// 添加一个新字段 "email" 需要修改：

// 1. User.java - 添加字段
private String email;

// 2. UserDTO.java - 添加字段
private String email;

// 3. UserRepository.java - 修改查询
"SELECT id, name, email FROM users"

// 4. UserService.java - 修改方法
public UserDTO toDTO(User user) {
    return new UserDTO(user.getId(), user.getName(), user.getEmail());
}

// 5. UserController.java - 修改响应
// 6. UserMapper.java - 修改映射
// 7. UserValidator.java - 添加验证
// ...

// 问题：一个简单变更需要修改7个文件
// 解决：减少层数，让数据自动流动