---
name: tech-research-and-reuse
description: 定义期第 3 步，技术调研与复用：在需求、不变式与总边界之下选技术，先找现成的库、相近系统或社区实现，自造要有论证。总边界定好，或人说「有没有现成的」「选型」「要不要自己写」时加载。实现里顺手选一个库不加载。
---

# 技术调研与复用

能复用的不自造。除非论证了必须只有自己造轮子，否则直接复用、二次开发或二次封装。这一步在顶层设计之后，因为调研的范围由总边界限定；在细化设计之前，因为选型决定了细化设计的形状。

选型是思维模型 `think-ought-vs-is` 的一次应用：需求与不变式是应然，候选现在的公开行为是实然，两者的差异决定落在下表哪一档。

## 次序

按这个次序找，找到就停，往下走要说出上一档为什么不行：

| 档 | 做法 | 停下的条件 |
| --- | --- | --- |
| 1 直接复用 | 现成的库、框架、服务，按它的公开接口用 | 满足需求与不变式，许可证与维护状态可接受 |
| 2 二次开发 | 在现成实现上改，或用它的扩展点 | 差异小、上游活跃、改动能回馈或长期跟得住 |
| 3 二次封装 | 现成实现不动，外面包一层把它的形状对齐到本系统的契约 | 差异在接口形状而不在行为 |
| 4 自造 | 自己实现 | 前三档都写出了具体的不行理由，并且自造的范围被压到最小 |

「不行」要具体：缺哪个行为，违反哪条不变式，许可证哪一条，维护状态是什么。「不够优雅」「想自己掌控」不算理由。

## 调研的做法

加载技能 `mattpocock-skills:research`：对着高可信的一手来源查，把结论写成带引用的文件。查的对象：

- 候选库与框架：公开接口、行为边界、性能特征、许可证、最近一年的维护记录。
- 相近系统：同类产品怎么划边界、它们故意不做什么。
- 社区实现：可参考的实现与它们踩过的坑。

调研先列候选再比较，不先选后找理由。每个候选对照需求的三问和不变式清单逐条核，不核的条目不写「满足」。

## 自造的论证

走到第 4 档要写论证，内容固定：前三档各自的不行理由；自造的最小范围；自造部分要守的不变式；以后出现合适的现成实现时怎样替换。论证进 spec 的已定事项。

## 产出

填[复用论证单](reuse-template.md)。单子的结论只有四种：直接复用、二次开发、二次封装、自造。每种都带候选、依据、不变式对照。

## 外部技能

- 先删再加：引入新依赖前先看有没有能删掉的旧依赖或重复实现，加载技能 `pstack:principle-subtract-before-you-add`。