code-review-refactor

# Code Review & Refactor 规范 Skill 当用户提出“代码很乱 / 需要 Code Review / 重构不够规范 / 提取可复用逻辑 / CSS 太多 / 页面重复应该 JSON 驱动”等诉求时，使用本 Skill。 ## 0. 使用范围（When to Use） - 用户明确说要 Code Review - 或用户反馈：组件/页面冗长、CSS 重复、相似页面太多、缺少抽取到 `utils/composables/services`、缺少可复用结构 - 或发现你在修改时重复造轮子（应优先提取/复用） ## 1. 重构总原则（必须遵守） 1. **行为优先（Behavior First）**：重构仅做结构优化，不改变既有功能、接口与用户交互语义。 2. **小步可验证**：每次改动都应能局部验证；先提取再替换，避免“一次大改导致难排查”。 3. **优先抽取可复用逻辑**： - 纯函数与可复用算法：`app/utils/` - 与组件生命周期/状态联动的逻辑：`app/composables/` - API 请求/数据转换：`app/services/` 4. **优先组件化重复 UI**： - 动作按钮组、筛选条、分页条、表格工具栏等重复结构 -> 公共组件 - 相似页面 -> 用“配置/JSON + 事件绑定”做驱动，而不是拷贝复制页面 5. **CSS 去重**： - 多处重复的 CSS -> 提取为组件内共用 class，或提取公共样式（同风格、同作用域规则） - 只为“一个小变量”复制 CSS 的 -> 合并成同一个 class + 参数化/状态类 ## 2. Code Review 检查清单（Checklists） ### 2.1 逻辑抽取（Logic Extraction） 在 review 时，逐段检查是否存在以下情况： 1. 一个组件里出现多次相同的处理逻辑（如 parse/safeParse/格式化/渲染拼装）。 2. 多个页面存在相同的业务流程（如同一类 SSE 流式组装、同一类 markdown/eCharts 渲染触发）。 3. 与页面无关的纯逻辑没有被移到 `utils` 或 `composables`。 输出要求： - 指出“重复点”与“提取位置建议”（utils/composables/services 哪个更合适） - 给出新的接口/函数签名建议（至少用参数名与返回类型描述） ### 2.2 组件拆分（Componentization） - 组件文件是否超过合理规模（建议阈值：500 行内易维护，复杂组件建议拆子组件） - 是否存在“混杂多职责”（例如：渲染 + 请求 + 状态 + 事件处理全部写在一个组件） 输出要求： - 提出“拆分方案”：哪些子组件/哪些 composables - 标明拆分后组件仍保持同样的 Props/事件语义 ### 2.3 CSS 去重（CSS De-duplication） 检查： 1. 不同组件/页面有大量相同 CSS（尤其是 `markdown-body`、code block、card spacing、按钮样式等）。 2. 相同选择器重复定义或只差少量颜色/间距。 输出要求： - 优先给出“提取成一个 class”方案 - 或建议做“公共样式组件/公共 wrapper 组件”（如果是 UI 结构层面的重复） ### 2.4 JSON 驱动的页面复用（Config-Driven Pages） 当你发现多个管理页面“按钮数量不同、内容通过 JSON 稍有差异”，建议使用 JSON 驱动： - 页面结构拆为通用骨架： - 顶部标题区 - 操作按钮组（来自配置） - 表格/列表区（列定义来自配置） - 弹窗/抽屉（表单字段来自配置） - 事件由页面注入（例如：`onAction(actionKey, payload)` 或通过映射表） 输出要求： - 提出一个“最小通用配置 schema”（字段列表 + 示例） - 指出每个页面需要补充的差异化配置项 ### 2.5 TypeScript 与安全护栏 检查是否存在： - `arr[i]` 取值后未做 TS 收窄导致 `T | undefined` 警告 - SSE/流式数据拼接在 TS 层面不安全 输出要求： - 给出 TS 收窄的推荐写法（局部变量 + if 守卫 / type guard） ## 3. 推荐的输出格式（必须用） 当用户说开始 Code Review 时，你的回答应使用以下结构（按序）： 1. `## 最关键问题（按严重度从高到低）` - 每条用一句话概括 + 标明影响范围（渲染/性能/可维护性/正确性） 2. `## 重构/复用建议（可落地）` - 对每条建议写：提取目标（utils/composables/services/组件/CSS）、原因、预计收益 3. `## JSON 驱动复用方案（如果存在重复页面）` - 给出配置 schema（字段列表）+ 示例（可以是伪 JSON） 4. `## 验证与回归（Test Plan）` - 给出最少的手动验证清单（UI 是否一致、功能是否不变、关键交互是否回归） ## 4. 允许与禁止 允许： - 提取公共逻辑、拆子组件、创建新 util/composable/services - CSS 合并、抽取公共 class、增加必要 wrapper 组件 禁止： - 仅为“看起来更漂亮”而改变现有交互语义或数据结构 - 大而全的重写（除非用户明确要求并且能接受高风险）