clj-refactor

扫描指定的文件或目录，依据以下原则查找改进机制与策略分离的机会。

查找内容

根据 Arne Brasseur 的定义：

机制是指符合以下特征的代码：

• 不带偏见，且不依赖上下文
• 可在不同业务领域中重复使用
• 易于单独测试
• 稳定——随时间变化缓慢

策略是指符合以下特征的代码：

• 带有倾向——反映当前的业务决策
• 依赖上下文——与特定领域相关
• 预期会频繁变化

两者的区别不在于代码做了什么，而在于代码是如何编写的。 目标是推动代码向这一光谱的两端靠拢。

诊断启发式

评估代码在光谱中的位置时，请思考：

• 此代码是否将所有依赖项作为显式参数接收， 还是依赖默认值、全局变量或隐式上下文？ （越显式 → 越偏向机制）

• 如果要在其他地方重用这段逻辑，你会使用不同的参数调用它， 还是复制粘贴后再修改？ （参数化重用 → 机制；复制粘贴重用 → 策略）

• 这段代码表达的是稳定的技术事实，还是当前的业务决策？ 业务决策应归入策略。

• 这些值有多大程度是硬编码的？硬编码常量表明策略已渗入机制。

• 此代码是否优先考虑便利性（易用）而非显式性 （简单）？以便利为导向的默认值，往往是渗入机制的策略。

你的任务

对于检查的每个文件或模块，请报告：

1. 混合代码——机制与策略纠缠在一起的函数或模块。说明混合了哪些内容，以及应在哪里划分边界。

2. 可提取项——目前嵌入策略代码中的机制部分，可提取到独立模块或库中。对于每个候选项，请说明它为何属于机制（不依赖上下文、稳定、可重用）。

3. 错置的策略——已渗入本应属于底层机制的业务逻辑。说明隐藏了什么假设，以及该逻辑应归于何处。

4. 建议的重构——针对每项发现，提出具体的重构方案。展示重构前后的结构，而不只是阐述原则。

约束

• 不要过早重构。只有在至少两个不同用例中出现某种模式时，才建议提取。
• 保留现有行为。这是结构性重构，不是重写业务逻辑。
• 建议必须以实际代码为依据。不要提出在当前代码库中没有证据支持的抽象。