name: 保持生产性张力 description: 识别当分歧揭示有价值上下文时，保留多种有效方法而不是强制过早解决 when_to_use: 当在优化不同合法优先级的同等有效方法之间摇摆时 version: 1.1.0

保持生产性张力

概述

有些张力不是要解决的问题——而是要保留的有价值信息。当多种方法在不同上下文中真正有效时，强制选择会破坏灵活性。

核心原则： 保留揭示上下文依赖性的张力。仅在必要时强制解决。

识别生产性张力

张力是生产性的当：

两种方法优化不同的合法优先级（成本 vs 延迟、简单性 vs 功能）
“更好”的选择取决于部署上下文，而不是技术优越性
不同用户/部署会选择不同的方法
权衡是真实的，不会因巧妙的工程而消失
利益相关者有冲突但有效的关切

张力需要解决的当：

保留两者的实现成本过高
方法在根本上冲突（无法共存）
在特定用例中存在明确的技术优越性
这是单向门（选择锁定架构）
保留两者添加复杂性而无价值

保留模式

模式1：配置

使选择可配置，而非硬编码到架构中：

class Config:
    mode: Literal["optimize_cost", "optimize_latency"]
    # 每种模式都有干净、简单的实现

何时使用： 两种方法在架构上兼容，切换是运行时决策

模式2：并行实现

将两者作为独立的干净模块维护，共享契约：

# processor/batch.py - 优化成本
# processor/stream.py - 优化延迟
# 两者都实现：def process(data) -> Result

何时使用： 方法显著分歧，但共享相同接口

模式3：文档化权衡

在文档/决策记录中明确捕捉张力：

## 未解决的张力：身份验证策略

**选项A：JWT** - 无状态，易于扩展，但令牌撤销困难
**选项B：会话** - 易于撤销，但需要共享状态

**为什么未解决：** 不同部署需要不同的权衡
**决策推迟到：** 部署配置
**审查触发条件：** 如果80%的部署选择一个选项

何时使用： 无法在代码中保留两者，但需要文档化选择是故意的

红旗——你正在强制解决

当两者都有效时，问“哪个最好？”
“我们需要选一个”而不解释原因
根据你的偏好 vs 用户上下文选择
为了“取得进展”而解决张力，而保留它们本身就是进展
当多样性有价值时，强制共识

所有这些都是指：停止。考虑保留张力。

何时强制解决

你应该强制解决的当：

实现成本过高
- 构建/维护两者会显著减缓开发
- 团队没有带宽进行并行方法
根本性冲突
- 方法做出矛盾的架构假设
- 无法干净地分离关注点
明确的技术优越性
- 一种方法在特定上下文中有明显更好的客观优势
- 不是“我更喜欢X”，而是“X解决我们的约束，Y不”
单向门
- 选择锁定我们进入一个架构
- 在选项之间迁移会昂贵
简单性需要选择
- 保留两者确实添加复杂性
- YAGNI：如果我们只需要一个，不要构建两者

明确提问： “我应该选择一个，还是保留两者作为选项？”

文档格式

当保留张力时，清楚文档化：

## 张力：[名称]

**上下文：** [为什么此张力存在]

**选项A：** [方法]
- 优化： [优先级]
- 权衡： [成本]
- 最佳当： [上下文]

**选项B：** [方法]
- 优化： [不同优先级]
- 权衡： [不同成本]
- 最佳当： [不同上下文]

**保留策略：** [配置/并行/文档化]

**解决触发条件：** [强制选择一个的条件]

示例

生产性张力（保留）

“我们应该优化成本还是延迟？”

答案： 使其可配置——不同部署需要不同的权衡

技术决策（解决）

“我们应该使用SSE还是WebSockets？”

答案： SSE——我们只需要单向通信，实现更简单

业务决策（推迟）

“我们应该支持离线模式吗？”

答案： 不要保留两者——基于用户需求让利益相关者决定

记住

合法优先级之间的张力是特性，不是错误
过早共识破坏有价值的灵活性
配置 > 强制选择（当合理时）
明确文档化权衡
当有理由时，解决是好的