@tinkcarlos/skillora 0.2.0

package/.claude/skills/skill-expert-skills/references/domain-knowledge/bug-fixing-expertise.md

@@ -0,0 +1,363 @@
+# Bug Fixing 领域专业知识库
+
+> 创建日期: 2025-01-15
+> 知识来源: 深度研究 + 行业最佳实践
+> 适用场景: 优化/创建 bug-fixing 相关 Skills
+
+---
+
+## 目录
+
+1. [核心概念](#1-核心概念)
+2. [调试心智模型](#2-调试心智模型)
+3. [根因分析 (RCA)](#3-根因分析-rca)
+4. [Bug 分类与优先级](#4-bug-分类与优先级)
+5. [影响分析](#5-影响分析)
+6. [验证与回归预防](#6-验证与回归预防)
+7. [知识沉淀](#7-知识沉淀)
+8. [常见陷阱](#8-常见陷阱)
+9. [工具与技术](#9-工具与技术)
+
+---
+
+## 1. 核心概念
+
+### 1.1 Bug 的本质
+
+**Bug 不是代码问题，而是假设问题。**
+
+> "Most bugs are not caused by bad code, but by unverified assumptions."
+> — [FreeCodeCamp: Why is Debugging Hard?](https://www.freecodecamp.org/news/why-is-debugging-hard-how-to-develop-an-effective-debugging-mindset/)
+
+关键洞察：
+- Bug 是预期行为与实际行为的差异
+- 根因通常是开发者对系统行为的错误假设
+- 修复 Bug 的核心是验证和纠正假设
+
+### 1.2 调试 vs 猜测
+
+| 调试 (Debugging) | 猜测 (Guessing) |
+|------------------|-----------------|
+| 系统性调查 | 随机尝试 |
+| 假设驱动 | 反应驱动 |
+| 问"为什么这个 Bug 必须存在？" | 问"怎么让它消失？" |
+| 修复根因 | 掩盖症状 |
+
+**反模式：反应式调试 (Reaction-based Debugging)**
+- 随机修改代码希望错误消失
+- 不理解为什么修复有效
+- 高概率引入新 Bug
+
+---
+
+## 2. 调试心智模型
+
+### 2.1 科学方法调试框架
+
+来源: [FreeCodeCamp](https://www.freecodecamp.org/news/why-is-debugging-hard-how-to-develop-an-effective-debugging-mindset/)
+
+```
+Bug 发现 → 定义事实 → 识别假设 → 形成假设 → 验证假设 → 修复
+```
+
+**5 步框架详解：**
+
+| 步骤 | 目标 | 关键问题 |
+|------|------|----------|
+| 1. Bug 发现 | 记录意外行为 | 有证据吗？(日志/截图/复现步骤) |
+| 2. 定义事实 | 只写能证明的 | 这是事实还是猜测？ |
+| 3. 识别假设 | 暴露隐藏信念 | 代码正常工作需要什么条件？ |
+| 4. 形成假设 | 因果陈述 | 如果这个假设错了，行为就说得通 |
+| 5. 验证假设 | 有目的地使用工具 | 假设是真是假？ |
+
+**核心原则：**
+> "Never touch the fix until the hypothesis survives reality."
+
+### 2.2 事实 vs 假设
+
+| 事实 (Facts) | 非事实 (Not Facts) |
+|--------------|-------------------|
+| "这个组件渲染了两次" | "React 表现异常" |
+| "API 返回正确数据" | "在我机器上能用" |
+| "日志显示 X 在 Y 之前执行" | "应该不会有并发问题" |
+
+### 2.3 假设验证工具
+
+| 工具 | 用途 | 何时使用 |
+|------|------|----------|
+| console.log / print | 追踪执行流程 | 验证代码是否执行 |
+| 断点调试 | 检查状态 | 验证变量值 |
+| 网络检查 | API 交互 | 验证请求/响应 |
+| git bisect | 定位引入点 | 验证"何时开始出问题" |
+
+---
+
+## 3. 根因分析 (RCA)
+
+### 3.1 5 Whys 技术
+
+来源: [Pragmatic Coders RCA Guide](https://www.pragmaticcoders.com/blog/root-cause-analysis-rca-a-complete-guide-for-engineering-qa-and-business-teams)
+
+**核心洞察：**
+> "The solution is almost always process-related, because it's almost always the process's fault."
+
+**示例：**
+```
+问题：用户无法登录
+Why 1: 密码验证失败 → 为什么？
+Why 2: 密码哈希不匹配 → 为什么？
+Why 3: 使用了错误的哈希算法 → 为什么？
+Why 4: 迁移脚本没有更新算法 → 为什么？
+Why 5: 迁移检查清单没有包含算法验证 → 根因！
+```
+
+**关键：** 真正的根因通常在 3-5 层深度
+
+### 3.2 三路径 RCA 框架
+
+| 路径 | 问题 | 关注点 |
+|------|------|--------|
+| 1. 为什么有这个 Bug？ | 需求/设计/实现哪里出了问题？ | 预防 |
+| 2. 我们如何响应？ | 错误信息清晰吗？用户能恢复吗？ | 体验 |
+| 3. 我们如何修复？ | 修复完整吗？历史数据处理了吗？ | 彻底性 |
+
+### 3.3 何时进行正式 RCA
+
+**适合 RCA 的场景：**
+- 严重生产事故（宕机、客户流失）
+- 同一区域反复出现问题
+- 需要流程变更，而非仅仅热修复
+- 团队陷入"返工模式"
+
+**不需要正式 RCA：**
+- 小 Bug → 迷你回顾即可
+- 一次性问题
+- 已知原因的问题
+
+### 3.4 RCA 常见陷阱
+
+| 陷阱 | 表现 | 解决方案 |
+|------|------|----------|
+| 追责导向 | 停在"Chris 忘了" | 问"为什么忘记是可能的？" |
+| 分析过浅 | 只到第 1-2 层 | 坚持到 3-5 层 |
+| 无心理安全 | 人们不敢承认错误 | 建立无责文化 |
+| 无落地 | 结论留在文档里 | 更新 DoR/DoD |
+| 忽略历史数据 | 只修新记录 | 检查旧数据是否受影响 |
+
+---
+
+## 4. Bug 分类与优先级
+
+### 4.1 P0-P4 分类体系
+
+来源: [Fibery Bug Prioritization Guide](https://fibery.io/blog/product-management/bug-prioritization/)
+
+| 级别 | 名称 | 严重程度 | 响应 |
+|------|------|----------|------|
+| **P0** | 立即修复 | 崩溃/安全漏洞/数据丢失 | 放下一切，立即修复 |
+| **P1** | 高优先级 | 主要功能受损但不崩溃 | 当前周期内修复 |
+| **P2** | 重要但不紧急 | 中等问题，非核心功能 | 按常规排期修复 |
+| **P3** | 有空再修 | 小问题，UI 瑕疵 | 未来 Sprint 处理 |
+| **P4** | 最低优先级 | 微小问题，错别字 | 有空时处理 |
+
+### 4.2 优先级评估维度
+
+| 维度 | 问题 | 权重 |
+|------|------|------|
+| 用户影响 | 多少用户受影响？体验多差？ | 高 |
+| 发生频率 | 偶发还是频繁？ | 高 |
+| 业务关键性 | 影响核心功能/收入吗？ | 高 |
+| 修复复杂度 | 需要多少时间/资源？ | 中 |
+| 修复风险 | 可能引入新 Bug 吗？ | 中 |
+| 变通方案 | 有临时解决办法吗？ | 中 |
+| 公众关注 | 社交媒体/论坛有讨论吗？ | 中 |
+| 合规风险 | 涉及安全/隐私/法规吗？ | 高 |
+
+### 4.3 务实观点
+
+> "Not every bug needs to be fixed... obsessing over every tiny bug can lead us down a rabbit hole of inefficiency."
+> — Fibery PM
+
+**策略：** P3/P4 Bug 可以暂时搁置，只要 P0/P1 处理得当
+
+---
+
+## 5. 影响分析
+
+### 5.1 影响分析类型
+
+来源: [Wikipedia: Change Impact Analysis](https://en.wikipedia.org/wiki/Change_impact_analysis)
+
+| 类型 | 方法 | 适用场景 |
+|------|------|----------|
+| **追溯性分析** | 追踪需求→设计→代码→测试的链接 | 评估变更范围 |
+| **依赖性分析** | 分析代码/模块/变量间的依赖 | 评估技术影响 |
+| **经验性分析** | 专家判断、团队讨论 | 快速评估 |
+
+### 5.2 5 层影响追踪
+
+| 层级 | 追踪内容 | 示例 |
+|------|----------|------|
+| 1. 变更代码 | 直接修改了什么 | 修改了 `validateUser()` |
+| 2. 直接调用者 | 谁直接调用它 | `LoginController` 调用 |
+| 3. 间接调用者 | 谁调用调用者 | `AuthMiddleware` |
+| 4. 跨模块 | 共享工具/事件/导入 | 其他模块也用 `validateUser` |
+| 5. 系统级 | API/数据库/缓存/任务 | 影响 Session 存储 |
+
+### 5.3 依赖地狱 (Dependency Hell)
+
+修改一处代码可能触发连锁反应。工具支持：
+- IDE 依赖分析
+- 静态分析工具 (FindBugs, Visual Expert)
+- 包管理器依赖检查
+
+---
+
+## 6. 验证与回归预防
+
+### 6.1 零回归矩阵
+
+| 检查项 | 验证方法 |
+|--------|----------|
+| 修复有效 | 原始 Bug 不再复现 |
+| 无新 Bug | 相关功能仍正常 |
+| 边界情况 | 极端输入测试 |
+| 跨平台 | 不同环境验证 |
+| 性能 | 无性能退化 |
+
+### 6.2 Git Bisect 技术
+
+来源: [Expert Beacon: Git Bisect](https://expertbeacon.com/how-git-bisect-makes-debugging-easier/)
+
+**用途：** 二分查找定位引入 Bug 的提交
+
+```bash
+git bisect start
+git bisect bad HEAD
+git bisect good v1.0.0
+# Git 自动检出中间提交，测试后标记 good/bad
+# 重复直到找到引入 Bug 的提交
+```
+
+### 6.3 修复后代码审查
+
+**必检项：**
+- 修复是否完整（不只是掩盖症状）
+- 是否引入新依赖
+- 是否影响其他调用者
+- 测试覆盖是否充分
+- 是否需要更新文档
+
+---
+
+## 7. 知识沉淀
+
+### 7.1 Bug 知识库价值
+
+- 避免重复踩坑
+- 加速未来调试
+- 团队知识共享
+- 模式识别
+
+### 7.2 Bug 记录模板
+
+```markdown
+## Bug ID: BUG-XXX
+
+### 症状
+[用户看到什么]
+
+### 根因
+[一句话总结]
+
+### 修复
+[做了什么改动]
+
+### 模式
+[可复用的教训]
+
+### 预防
+[如何避免类似问题]
+```
+
+### 7.3 模式提取
+
+从具体 Bug 提取通用模式：
+
+| 具体 Bug | 通用模式 |
+|----------|----------|
+| "用户 ID 为 null 导致崩溃" | "外部输入未验证" |
+| "并发请求导致数据不一致" | "共享状态无锁保护" |
+| "API 返回格式变化导致解析失败" | "外部依赖契约变更" |
+
+---
+
+## 8. 常见陷阱
+
+### 8.1 调试陷阱
+
+| 陷阱 | 表现 | 解决 |
+|------|------|------|
+| 过早修复 | 不理解就开始改代码 | 先验证假设 |
+| 假设即事实 | "应该不会有问题" | 区分事实和假设 |
+| 工具依赖 | 疯狂加日志但不分析 | 有目的地使用工具 |
+| 隧道视野 | 只看自己的代码 | 考虑系统交互 |
+
+### 8.2 修复陷阱
+
+| 陷阱 | 表现 | 解决 |
+|------|------|------|
+| 症状修复 | Bug "消失"但根因未解决 | 验证根因已修复 |
+| 过度修复 | 顺便重构了一堆代码 | 最小化变更 |
+| 忽略历史数据 | 只修新数据 | 检查旧数据影响 |
+| 无测试 | 修完就提交 | 添加回归测试 |
+
+### 8.3 流程陷阱
+
+| 陷阱 | 表现 | 解决 |
+|------|------|------|
+| 无优先级 | 所有 Bug 同等对待 | 使用 P0-P4 分类 |
+| 无追踪 | Bug 修了但没记录 | 维护 Bug 知识库 |
+| 无回顾 | 同样问题反复出现 | 定期 RCA |
+
+---
+
+## 9. 工具与技术
+
+### 9.1 调试工具
+
+| 类别 | 工具 | 用途 |
+|------|------|------|
+| 日志 | console.log, logging 框架 | 追踪执行流程 |
+| 断点 | IDE 调试器 | 检查运行时状态 |
+| 网络 | DevTools Network, Postman | API 调试 |
+| 版本 | git bisect, git blame | 定位变更 |
+| 静态分析 | ESLint, TypeScript, FindBugs | 提前发现问题 |
+
+### 9.2 RCA 工具
+
+| 工具 | 用途 |
+|------|------|
+| Miro/Mural | 可视化映射 |
+| Confluence/Notion | 文档记录 |
+| Jira | Bug 收集和分组 |
+
+### 9.3 测试工具
+
+| 类别 | 工具 |
+|------|------|
+| 单元测试 | Jest, pytest, JUnit |
+| 集成测试 | Cypress, Playwright |
+| 回归测试 | 自动化测试套件 |
+
+---
+
+## 参考资料
+
+- [FreeCodeCamp: Why is Debugging Hard?](https://www.freecodecamp.org/news/why-is-debugging-hard-how-to-develop-an-effective-debugging-mindset/)
+- [Pragmatic Coders: RCA Complete Guide](https://www.pragmaticcoders.com/blog/root-cause-analysis-rca-a-complete-guide-for-engineering-qa-and-business-teams)
+- [Fibery: Bug Prioritization Guide](https://fibery.io/blog/product-management/bug-prioritization/)
+- [Wikipedia: Change Impact Analysis](https://en.wikipedia.org/wiki/Change_impact_analysis)
+- [Expert Beacon: Git Bisect](https://expertbeacon.com/how-git-bisect-makes-debugging-easier/)
+- [Wikipedia: Debugging](https://en.wikipedia.org/wiki/Debugging)
+- [Wikipedia: Root Cause Analysis](https://en.wikipedia.org/wiki/Root-cause_analysis)