视差

在天文学中，视差是指从两个不同位置观察同一物体时产生的视位移。这种位移揭示了深度。没有它，宇宙就是平面的。

功能概述

视差迫使每一个重大决策在编写一行代码之前，都要通过五个同时存在的视角进行审视。这不是一份检查清单。也不是事后的反思。而是作为主要的推理模式。

大多数架构错误并非从所有角度看都是错的。它们错在没有人站立的那个角度。

五个视差透镜

每个透镜的工作方式

透镜1：用户

用户透镜不问用户体验好吗？——它问的是这个界面讲述了一个什么故事？

分析轴：
├── 认知负荷：用户需要同时记住多少件事？
├── 错误恢复：当他们（不是如果）犯错时，会发生什么？
├── 信任信号：这个交互是建立还是削弱信心？
├── 时间尊重：这是尊重用户的时间还是浪费它？
└── 可访问性：能力不同的人能否同样使用？

它能发现什么： 功能强大但不可用的特性。对开发者有意义但让用户困惑的流程。牺牲清晰度的效率优化。

透镜2：维护者

维护者透镜问的是什么会让下一个读这段代码的人感到困惑？

分析轴：
├── 命名清晰度：名称是否描述了实际行为？
├── 抽象深度：要理解它需要深入多少层？
├── 变更局部性：要改变这个行为，需要触及多少个文件？
├── 测试信心：如果我修改了它，测试会告诉我是否破坏了什么吗？
└── 所需知识：在这里工作需要哪些未写明的上下文？

它能发现什么： 需要部落知识的巧妙代码。模糊而非清晰的抽象。对编写最优但对阅读不友好的设计。

透镜3：运维者

运维者透镜问的是当它在假期周末的凌晨3点失败时会发生什么？

分析轴：
├── 可观测性：我能否在不阅读源代码的情况下看到发生了什么？
├── 失败模式：它是大声失败、安静失败，还是看起来像成功的失败？
├── 恢复路径：我能否在不部署的情况下修复它？
├── 爆炸半径：如果这个失败，还有什么会失败？
└── 资源行为：它是优雅降级还是悬崖式崩溃？

它能发现什么： 没有日志记录的系统。静默级联的故障。需要原始开发者的恢复路径。只在生产负载下显现的内存泄漏。

透镜4：对手

对手透镜问的是哪里假设了善意？

分析轴：
├── 信任边界：外部输入从哪里进入？
├── 假设面：如果我对这个系统撒谎，什么会崩溃？
├── 权限范围：它拥有比所需更多的访问权限吗？
├── 信息泄露：错误消息揭示了什么？
└── 时序攻击：我能从事物花费的时间中了解秘密吗？

它能发现什么： 验证了格式但未验证意图的输入。揭示内部架构的错误消息。信任客户端状态的API。不存在的速率限制。

透镜5：赞助者

赞助者透镜问的是这推进了使命还是只是让人感觉有生产力？

分析轴：
├── 价值交付：这解决了有人愿意付费的问题吗？
├── 机会成本：在构建这个的同时，我们没有构建什么？
├── 价值实现时间：多久才能产生可衡量的影响？
├── 可逆性：如果这是错的，纠正的成本有多高？
└── 杠杆效应：这是倍增未来能力还是只是线性增加？

它能发现什么： 针对低价值问题的过度工程化解决方案。改善代码质量但延迟功能的重构。投资回报率不明确的基础设施投资。

视差流程

输入：一个提议的变更、功能或架构决策

步骤1：单视角遍历
├── 生成默认分析（自然产生的任何视角）
└── 记录：你本能地使用了哪个透镜？

步骤2：完整视差
├── 运行其余四个透镜
├── 对于每个透镜，生成：
│ ├── 从这个视角出发的首要关注点
│ ├── 这个透镜揭示的盲点
│ └── 这个视角要求的修改
└── 标记透镜之间的冲突

步骤3：三角测量
├── 识别3个以上透镜达成一致的地方（高置信度）
├── 识别透镜冲突的地方（设计张力）
├── 对于每个冲突：
│ ├── 在当前项目阶段哪个透镜具有优先权？
│ ├── 张力能否解决还是必须被管理？
│ └── 最不坏的权衡是什么？
└── 生成带有明确权衡图的最终建议

输出：具有完整视角覆盖和记录权衡的决策

冲突解决矩阵

当透镜不一致时，优先级取决于项目阶段：

输出格式

╔══════════════════════════════════════════════════════════════╗
║ 视差分析 ║
║ 决策：为用户API添加缓存层 ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 👤 用户： 响应更快(+)。数据过时风险(-)。 ║
║ → 确保个人资料变更时缓存立即失效。 ║
║ ║
║ 🔧 维护者： 新的复杂性层(-)。清晰的边界(+)。 ║
║ → 缓存必须是可替换的接口， ║
║ 而非硬编码到Redis。 ║
║ ║
║ 📟 运维者： 减少数据库负载(+)。新的故障点(-)。 ║
║ → 需要缓存命中/未命中指标和 ║
║ 优雅回退到直接数据库。 ║
║ ║
║ 🗡️ 对手： 缓存投毒向量(-)。通过缓存绕过速率限制(-)。 ║
║ → 缓存键不能由用户控制。 ║
║ ║
║ 💼 赞助者： 减少基础设施成本(+)。延迟功能X(-)。 ║
║ → 仅当当前p95延迟实际导致用户流失时才有价值。║
║ ║
║ 冲突： ║
║ ├── 用户（新鲜度）vs 运维者（数据库负载）→ TTL权衡 ║
║ └── 赞助者（成本）vs 维护者（复杂性）→ 阶段检查 ║
║ ║
║ 建议：继续推进，使用60秒TTL、可替换接口、 ║
║ 缓存指标仪表板和缓存投毒防护。 ║
║ 如果p95延迟低于200ms则推迟。 ║
╚══════════════════════════════════════════════════════════════╝

何时调用

• - 在任何难以逆转的架构决策之前
• 在设计评审和RFC讨论期间
• 当决策感觉正确但无法阐明原因时（你被困在一个透镜中）
• 当利益相关者意见不一致时（他们各自通过不同的透镜看问题）
• 在添加任何新的依赖、服务或抽象层之前

为何重要

架构遗憾的头号原因不是选择了错误的解决方案。而是选择了一个从某个视角看最优、但从另一个无人考虑的视角看却是灾难性的