codebase-design
设计深层模块的共享词汇。当用户想要设计或改进模块接口、寻找深化机会、决定缝合点放在哪里、使代码更可测试或更适合 AI 导航,或当其他技能需要深层模块词汇时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
设计深层模块的共享词汇。当用户想要设计或改进模块接口、寻找深化机会、决定缝合点放在哪里、使代码更可测试或更适合 AI 导航,或当其他技能需要深层模块词汇时使用。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
询问哪种技能或流程适合你的情况。本仓库技能的导航器。
沿两个轴线审查自某个固定点(commit、分支、tag 或合并基准)以来的变更 — 标准(代码是否遵循此仓库已记录的编码规范?)和规范(代码是否匹配原始 issue/PRD 要求的内容?)。以并行子 agent 运行两项审查,并将结果并排呈现。当用户想要审查分支、PR、进行中的变更,或要求"从 X 开始审查"时使用。
针对疑难 bug 和性能回归的诊断循环。当用户说"诊断"/"调试这个",或报告有东西损坏/抛出异常/失败/变慢时使用。
构建和精炼项目的领域模型。当用户想要确定领域术语或通用语言、记录架构决策,或当其他技能需要维护领域模型时使用。
一场无情的面试,用于打磨方案或设计。
一场无情的访谈,用于打磨计划或设计,同时在此过程中创建文档(ADR 和词汇表)。
| name | codebase-design |
| description | 设计深层模块的共享词汇。当用户想要设计或改进模块接口、寻找深化机会、决定缝合点放在哪里、使代码更可测试或更适合 AI 导航,或当其他技能需要深层模块词汇时使用。 |
设计深层模块:通过一个小接口承载大量行为,放置在干净的缝合点处,可通过该接口进行测试。在任何设计或重构代码的地方使用这些语言和原则。目标是为调用者提供杠杆效应,为维护者提供局部性,为所有人提供可测试性。
严格使用以下术语 — 不要用 "component"、"service"、"API" 或 "boundary" 替代。一致的语言才是重点。
Module(模块) — 任何具有接口和实现的东西。有意识地与规模无关:函数、类、包或跨层切片。避免使用:unit、component、service。
Interface(接口) — 调用者正确使用模块所需了解的一切:类型签名,还包括不变量、顺序约束、错误模式、必需配置和性能特征。避免使用:API、signature(太窄 — 它们仅指类型层面的表面)。
Implementation(实现) — 模块内部的内容,它的代码体。区别于 Adapter(适配器):一个东西可以是一个小适配器加一个大实现(Postgres 仓库),也可以是一个大适配器加一个小实现(内存假实现)。当讨论缝合点时用 "adapter";否则用 "implementation"。
Depth(深度) — 接口处的杠杆效应:调用者(或测试)每学习一个单位的接口可以驱动的行为量。当大量行为隐藏在小接口后面时,模块是深层的;当接口几乎和实现一样复杂时,模块是浅层的。
Seam(缝合点) (Michael Feathers) — 一个可以在不编辑该位置的情况下改变行为的地方;模块接口所在的位置。缝合点放在哪里本身就是一个设计决策,与缝合点后面放什么不同。避免使用:boundary(与 DDD 的有界上下文重载)。
Adapter(适配器) — 在缝合点处满足接口的具体事物。描述的是角色(它填充哪个槽位),而非实质(内部是什么)。
Leverage(杠杆效应) — 调用者从深度中获得的好处:每学习一个单位的接口获得更多的能力。一个实现为 N 个调用点和 M 个测试带来回报。
Locality(局部性) — 维护者从深度中获得的好处:变更、bug、知识和验证集中在一个地方,而非分散在调用者之间。一次修复,处处生效。
深层模块 = 小接口 + 大量实现:
┌─────────────────────┐
│ 小接口 │ ← 少量方法,简单参数
├─────────────────────┤
│ │
│ 深层实现 │ ← 隐藏的复杂逻辑
│ │
└─────────────────────┘
浅层模块 = 大接口 + 少量实现(应避免):
┌─────────────────────────────────┐
│ 大接口 │ ← 大量方法,复杂参数
├─────────────────────────────────┤
│ 薄实现 │ ← 仅仅是透传
└─────────────────────────────────┘
设计接口时,问自己:
良好的接口使测试变得自然:
接收依赖,不要创建依赖。
// 可测试
function processOrder(order, paymentGateway) {}
// 难以测试
function processOrder(order) {
const gateway = new StripeGateway();
}
返回结果,不要产生副作用。
// 可测试
function calculateDiscount(cart): Discount {}
// 难以测试
function applyDiscount(cart): void {
cart.total -= discount;
}
小表面积。 更少的方法 = 更少的测试需求。更少的参数 = 更简单的测试设置。
interface 关键字或类的公开方法:太窄 — 此处的接口包括调用者必须了解的每个事实。