mcpField
R
review-duplication

review-duplication

github.com/google-gemini测试与质量108.6k342 次安装今天更新
代码仓库

关于 review-duplication

review-duplication 是一套面向代码审查的调查流程，用于发现重复逻辑、已有工具的重新实现及未复用的项目模式。它指导审查者追踪代码库结构与依赖，并给出可落实的复用建议。

主要功能

  1. 01提取新增代码的核心逻辑
  2. 02追踪可能存在的实现与依赖
  3. 03委派子 Agent 调查代码库
  4. 04检查项目惯例与最佳实践
  5. 05提供带路径和方案的反馈

适用场景

  1. 01审查 PR 是否重复现有功能
  2. 02查找可复用的工具或 UI 组件
  3. 03检查新增依赖是否已有封装
  4. 04为重构建议提供具体依据

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/google-gemini/gemini-cli --skill review-duplication

安装后在 Claude Code 中输入/review-duplication确认已加载。

详细介绍

重复代码审查

概述

此技能提供了一套结构化工作流，用于在代码审查期间调查代码库，识别重复逻辑、重新实现的工具，以及错过的复用既有模式的机会。执行此工作流可确保新代码与现有项目架构无缝集成。

工作流：调查重复代码

审查代码时，请在完成审查前执行以下步骤：

1. 提取核心逻辑

分析新代码，识别其中引入的核心算法、工具函数、通用数据结构或 UI 组件。不要只关注具体业务逻辑，也要观察其底层机制。

2. 推测现有位置并追踪依赖关系

思考如果项目中已有这类代码，它可能位于何处。请使用从代码库根目录开始的绝对路径，以便明确定位。

  • 工具： packages/core/src/utils/、packages/cli/src/utils/
  • UI 组件： packages/cli/src/ui/components/、packages/cli/src/ui/
  • 服务： packages/core/src/services/、packages/cli/src/services/
  • 配置： packages/core/src/config/、packages/cli/src/config/
  • 核心逻辑： 如果功能看起来并非 React UI 特有，请指出 packages/core/。

追踪第三方依赖： 如果 PR 引入了新的工具库导入（例如 lodash.merge、date-fns），请追踪项目目前如何以及在何处使用该库。项目很可能已有封装或共享工具。

检查包文件： 在指出复杂算法的自定义实现之前，请检查 package.json，确认是否已安装提供该功能的标准库（例如 lodash 或 uuid）。

3. 调查代码库（委派给子 Agent）

将代码库调查中的繁重工作委派给专门的子 Agent。它们擅长执行深入搜索和语义映射，同时避免会话历史过于庞杂。

为确保审查全面，必须为子 Agent 制定高度具体的目标，并提供你在第 1 步中发现的“线索”。

  • 代码库调查员： 将 codebase_investigator 用作主要调查者。委派任务时，应提出具体的代码库调查问题，并明确包含以下搜索方向：
    • 结构相似性： 询问现有代码是否使用相同的底层 API（例如：“是否有现有代码使用 Intl.DateTimeFormat 或 setTimeout 实现类似功能？”）。
    • 命名约定： 询问是否存在命名模式相似的符号（例如：“是否存在命名模式类似 *Format* 或 *Debounce* 的符号？”）。
    • 注释和文档： 询问 PR 注释或 JSDoc 中的关键词是否也用于描述其他地方的类似行为。
    • 架构适配： 询问此类逻辑目前集中在哪里（例如：“集中处理日期格式化逻辑的位置在哪里？”）。
    • 重构建议： 关键是请子 Agent 说明如何重构新代码，以便使用它找到的任何现有逻辑。
  • 通用 Agent： 使用 generalist 进行需要多轮深入对比的详细分析。例如：“审查 PR 中 MyNewComponent 的实现，并与 packages/ui/src 中的所有组件进行语义对比。是否有现有组件可以扩展或复用？”
  • 保留简单搜索的快速路径： 对于极其简单且明确的检查（例如：“package.json 是否包含 lodash？”），直接搜索以节省时间。对于任何开放式“调查”，默认委派。
4. 评估最佳实践

检查新代码是否符合项目既定规范。

  • 错误处理： 是否使用项目标准的错误类或日志机制？
  • 状态管理： 是否绕过了既定的存储或上下文？
  • 样式： 是否硬编码了颜色或间距，而没有使用主题变量？ 如果 PR 引入了新模式，请将其与文档中记录的标准进行比较，并明确确认是否应该改用项目中已有的模式。
5. 提出建设性反馈

如果发现 PR 重复了现有功能或忽略了最佳实践：

  • 提供清晰的审查意见。
  • 指出来源： 明确提及应复用的代码所在的绝对路径或项目相对路径，以及具体符号（函数、组件、类）。
  • 提供实现指导： 提供简短的代码片段或清晰的说明，展示如何集成现有代码以满足任务要求。
  • 说明价值： 简要说明复用现有代码的好处（例如，可维护性、一致性、内置的边界情况处理）。

示例意见：

“这个 PR 似乎引入了新的 formatDate 工具函数。我们已经在 src/utils/dateHelpers.ts 中有一个经过充分测试的 formatDate 函数。

你可以像这样导入它来替换当前实现：

import { formatDate } from '../utils/dateHelpers';

// 然后在这里使用：
const displayDate = formatDate(userDate, 'MMM Do, YYYY');

复用该函数可以确保日期格式与应用的其他部分保持一致，并正确处理时区转换。”

评论

支持 Markdown