# Retro Coding

> 代码复盘——从正确性、健壮性、安全性、可维护性、性能等维度深度挖掘

- Skill: `kaixin1seu/retro-coding` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kaixin1seu/retro-coding`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kaixin1seu/retro-coding/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kaixin1seu (https://skillmd.com/u/kaixin1seu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kaixin1seu/retro-coding

---


# retro-coding — 代码复盘透镜

## 适用范围与边界

本 skill 覆盖代码编写、bug 修复和代码审查中的质量问题。

**与其它 skill 的区分**：
- 做了架构层面的设计决策（选型、分层）→ `retro-design`
- 代码中数据处理逻辑的问题 → `retro-data`
- 调试和排错的过程 → `retro-debugging`

**不适用场景**：架构选型/技术决策（用 retro-design）、算法设计（用 retro-experiment）、配置管理/部署脚本。

## 评估维度

### 1. 正确性
- 逻辑是否按预期工作？（不只是"看起来对"，是否验证过？）
- 边界条件是否覆盖？（空输入、极值、特殊字符、0、负数）
- 是否有 off-by-one 错误？
- 条件判断是否正确？（`>` vs `>=`、`and` vs `or`）

### 2. 健壮性与错误处理
- 错误是否被静默吞掉？（空的 except、没有日志的 catch）
- 外部依赖失败时是否有降级策略？（API 挂了、文件不存在、网络超时）
- 重试逻辑是否正确？（指数退避、最大重试次数、幂等性）
- 输入验证是否充分？（用户输入、文件内容、API 响应）
- 并发/异步场景下是否有竞态条件、死锁或异步异常处理遗漏？

### 3. 安全性
- 是否有硬编码的密钥/密码/Token？
- SQL 查询是否有注入风险？
- 文件路径是否有目录遍历风险？
- 敏感数据是否被意外记录到日志？
- 第三方依赖是否有已知漏洞？依赖版本是否过时？

### 4. 可维护性
- 命名是否清晰？（变量名、函数名一看就知道是干什么的）
- 函数是否单一职责？（一个函数做太多事？）
- 是否有必要的注释？（不是"做了什么"而是"为什么这样做"）
- 配置是否与代码分离？（硬编码的路径/阈值/参数？）

### 5. 性能与效率
- 是否有不必要的重复计算？
- 数据结构选择是否合理？
- 是否有 N+1 查询问题？
- 大文件/大数据是否流式处理而非全部加载到内存？

### 6. 测试
- 关键路径是否有测试？
- 边界条件是否被测试覆盖？
- 是否有回归测试防止老 bug 复发？

## 常见反模式

| 反模式 | 检测信号 |
|--------|----------|
| 静默失败 | 空的 try-except，没有日志输出的错误处理 |
| 硬编码 | 代码中出现具体路径、IP、密码、阈值数字 |
| 过度工程化 | 为"可能的"需求写了一大堆抽象，当前只用到一个 |
| 过早优化 | 牺牲可读性换取不一定需要的性能 |
| 复制粘贴 | 同样的逻辑出现两次以上但没有抽取 |
| 注释与代码不一致 | 代码改了但注释没更新 |
| 不验证输入 | 直接使用用户输入/文件内容/API 响应不检查 |
| 缺少测试 | 关键路径无测试覆盖，边界条件未被测试验证 |
| 测试覆盖不均 | 只测了 happy path，错误路径和边界条件零覆盖 |

## 已固化模式

| 模式 | 适用信号 | 验证 | 来源 |
|------|----------|------|
| （待复盘时自动追加） | | | |

## 关键追问

### 挑刺式（找改进空间）
- 如果这段代码明天就出 bug，最可能出在哪里？
- 什么输入会让这段代码崩溃？
- 错误信息是否足够让后来者快速定位问题？
- 这段代码给后面的人挖坑了吗？（有隐含假设没写清楚？）
- 有没有更简单但同样有效的实现方式？

### 正向式（找值得复用的）
- 这次写的代码中，有没有写得特别漂亮、下次可以直接复用的模块或模式？
  （信号：某段代码被反复引用/参考、某个函数签名设计得特别好、某个抽象在后续任务中直接复用无修改）
- 有没有某个错误处理/边界检查的方式特别有效，值得固化为编码习惯？
  （信号：这个检查方式在不止一处被用到、或在后续任务中拦截了潜在 bug）
- 有没有某个代码组织方式或命名约定被证明特别清晰，减少了后续维护的认知负担？

### 反证条件指引
对于代码的正确性假设，追问：**什么具体的输入或场景会让这段代码暴露出问题？**
（引导写出可操作的反证条件——如"如果输入 encoding 不是 UTF-8"而非空洞的"如果输入格式不对"）