Back to Details

review-duplication

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review Duplication

重复代码审查

Overview

概述

This skill provides a structured workflow for investigating a codebase during a code review to identify duplicated logic, reinvented utilities, and missed opportunities to reuse established patterns. By executing this workflow, you ensure that new code integrates seamlessly with the existing project architecture.
本技能提供了一套结构化工作流，供代码评审期间排查代码库，识别重复逻辑、重复实现的工具，以及错过的复用已有成熟模式的机会。执行该工作流可确保新代码与现有项目架构无缝集成。

Workflow: Investigating for Duplication

工作流：排查重复内容

When reviewing code, perform the following steps before finalizing your review:
评审代码时，在最终确定评审结论前执行以下步骤：

1. Extract Core Logic

1. 提取核心逻辑

Analyze the new code to identify the core algorithms, utility functions, generic data structures, or UI components being introduced. Look beyond the specific business logic to see the underlying mechanics.
分析新代码，识别其中引入的核心算法、工具函数、通用数据结构或UI组件。跳出具体业务逻辑，关注底层实现机制。

2. Hypothesize Existing Locations & Trace Dependencies

2. 推测现有存放位置并追踪依赖

Think about where this type of code would live if it already existed in the project. Provide absolute paths from the repo root to disambiguate.
  • Utilities: 
    packages/core/src/utils/
    , 
    packages/cli/src/utils/
  • UI Components: 
    packages/cli/src/ui/components/
    , 
    packages/cli/src/ui/
  • Services: 
    packages/core/src/services/
    , 
    packages/cli/src/services/
  • Configuration: 
    packages/core/src/config/
    , 
    packages/cli/src/config/
  • Core Logic: Call out 
    packages/core/
    if functionality does not appear React UI specific.
Trace Third-Party Dependencies: If the PR introduces a new import for a utility library (e.g., 
lodash.merge
, 
date-fns
), trace how and where the project currently uses that library. There is likely an existing wrapper or shared utility.
Check Package Files: Before flagging a custom implementation of a complex algorithm, check 
package.json
to see if a standard library (like 
lodash
or 
uuid
) is already installed that provides this functionality.
思考如果这类代码已经存在于项目中，可能会存放在什么位置。提供从仓库根目录开始的绝对路径以消除歧义：
  • 工具函数： 
    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. Investigate the Codebase (Sub-Agent Delegation)

3. 排查代码库（Sub-Agent 委派）

Delegate the heavy lifting of codebase investigation to specialized sub-agents. They are optimized to perform deep searches and semantic mapping without bloating your session history.
To ensure a comprehensive review, you MUST formulate highly specific objectives for the sub-agents, providing them with the "scents" you discovered in Step 1.
  • Codebase Investigator: Use the 
    codebase_investigator
    as your primary researcher. When delegating, formulate an objective that asks specific, investigative questions about the codebase, explicitly including these search vectors:
    • Structural Similarity: Ask if existing code uses the same underlying APIs (e.g., "Does any existing code use 
      Intl.DateTimeFormat
      or 
      setTimeout
      for similar purposes?").
    • Naming Conventions: Ask if there are existing symbols with similar naming patterns (e.g., "Are there existing symbols with naming patterns like 
      *Format*
      or 
      *Debounce*
      ?").
    • Comments & Documentation: Ask if keywords from the PR's comments or JSDoc exist in describing similar behavior elsewhere.
    • Architectural Fit: Ask where this type of logic is currently centralized (e.g., "Where is centralized date formatting logic located?").
    • Refactoring Guidance: Crucially, ask the sub-agent to explain how the new code could be refactored to use any existing logic it finds.
  • Generalist Agent: Use the 
    generalist
    for detailed, turn-intensive comparisons. For example: "Review the implementation of 
    MyNewComponent
    in the PR and compare it semantically against all components in 
    packages/ui/src
    . Are there any existing components that could be extended or used instead?"
  • Retain Fast Path for Simple Searches: For extremely simple, unambiguous checks (e.g., "Does 
    package.json
    include 
    lodash
    ?"), perform a direct search to save time. Default to delegation for any open-ended "investigations."
将代码库排查的繁重工作委派给专门的sub-agent，它们经过优化可以执行深度搜索和语义映射，不会让你的会话历史过于臃肿。
为确保评审全面，你必须为sub-agent制定高度明确的目标，向它们提供你在步骤1中发现的“线索”：
  • 代码库调查器： 使用
    codebase_investigator
    作为你的主要研究工具。委派任务时，制定的目标需要包含关于代码库的具体调查问题，明确包含以下搜索维度：
    • 结构相似性： 询问现有代码是否使用了相同的底层API（例如：“是否有现有代码出于类似目的使用
      Intl.DateTimeFormat
      或
      setTimeout
      ？”）
    • 命名约定： 询问是否存在命名模式相似的现有符号（例如：“是否存在命名模式类似
      *Format*
      或
      *Debounce*
      的现有符号？”）
    • 注释与文档： 询问PR注释或JSDoc中的关键词是否在其他地方用于描述相似行为。
    • 架构适配性： 询问这类逻辑当前的集中存放位置（例如：“集中的日期格式化逻辑位于哪里？”）
    • 重构指导： 关键一点，要求sub-agent说明如果找到现有逻辑，应该如何重构新代码来复用这些逻辑。
  • 通用Agent： 使用
    generalist
    进行需要多轮交互的详细对比。例如：“评审PR中
    MyNewComponent
    的实现，将其与
    packages/ui/src
    下的所有组件进行语义对比，是否有现有组件可以扩展或直接替代？”
  • 简单搜索保留快速通道： 对于极其简单、无歧义的检查（例如：“
    package.json
    中是否包含
    lodash
    ？”），直接执行搜索以节省时间。所有开放式“排查”任务默认使用委派方式。

4. Evaluate Best Practices

4. 评估最佳实践

Check if the new code aligns with the project's established conventions.
  • Error Handling: Does it use the project's standard error classes or logging mechanisms?
  • State Management: Does it bypass established stores or contexts?
  • Styling: Does it hardcode colors or spacing instead of using theme variables? If the PR introduces a new pattern, compare it against the documented standards and explicitly confirm if an existing project pattern should have been used instead.
检查新代码是否符合项目既定规范：
  • 错误处理： 是否使用了项目的标准错误类或日志机制？
  • 状态管理： 是否绕过了既定的存储或上下文？
  • 样式： 是否硬编码颜色或间距，而没有使用主题变量？ 如果PR引入了新的模式，将其与文档化的标准对比，明确确认是否应该使用现有项目模式。

5. Formulate Constructive Feedback

5. 给出建设性反馈

If you discover that the PR duplicates existing functionality or ignores a best practice:
  • Provide a clear review comment.
  • Identify the Source: Explicitly mention the absolute or project-relative file path and the specific symbol (function, component, class) that should be reused.
  • Implementation Guidance: Provide a brief code snippet or a clear explanation showing how to integrate the existing code to fulfill the task's requirements.
  • Explain the Value: Briefly explain why reusing the existing code is beneficial (e.g., maintainability, consistency, built-in edge case handling).
Example comment:
"It looks like this PR introduces a new 
formatDate
utility. We already have a robust, tested 
formatDate
function in 
src/utils/dateHelpers.ts
.
You can replace your implementation by importing it like this:
typescript
import { formatDate } from '../utils/dateHelpers';

// Then use it here:
const displayDate = formatDate(userDate, 'MMM Do, YYYY');
Reusing this ensures that the date formatting remains consistent with the rest of the application and handles timezone conversions correctly."
如果你发现PR重复了现有功能或违反了最佳实践：
  • 给出清晰的评审评论。
  • 指明来源： 明确提及应复用的绝对或项目相对文件路径，以及具体的符号（函数、组件、类）。
  • 实现指导： 提供简短的代码片段或清晰说明，展示如何集成现有代码来满足任务需求。
  • 说明价值： 简要解释复用现有代码的好处（例如：可维护性、一致性、内置的边界场景处理）。
示例评论：
"It looks like this PR introduces a new 
formatDate
utility. We already have a robust, tested 
formatDate
function in 
src/utils/dateHelpers.ts
.
You can replace your implementation by importing it like this:
typescript
import { formatDate } from '../utils/dateHelpers';

// Then use it here:
const displayDate = formatDate(userDate, 'MMM Do, YYYY');
Reusing this ensures that the date formatting remains consistent with the rest of the application and handles timezone conversions correctly."