review-duplication

Дублирование отзывов

Обзор

Данный навык обеспечивает структурированный рабочий процесс для анализа кодовой базы во время рецензирования кода с целью выявления дублирующейся логики, повторно реализованных утилит и упущенных возможностей повторного использования проверенных шаблонов. Выполняя этот рабочий процесс, вы гарантируете, что новый код будет органично интегрироваться в существующую архитектуру проекта.

Рабочий процесс: поиск дубликатов

При рецензировании кода выполните следующие шаги перед завершением рецензии:

1. Выделение основной логики

Проанализируйте новый код, чтобы выявить вводимые основные алгоритмы, служебные функции, общие структуры данных или компоненты пользовательского интерфейса. Не ограничивайтесь конкретной бизнес-логикой — обратите внимание на лежащие в основе механизмы.

2. Сформулируйте гипотезы о существующих местах размещения и проследите зависимости

Подумайте, где мог бы находиться код такого типа, если бы он уже существовал в проекте. Укажите абсолютные пути от корня репозитория, чтобы избежать неоднозначности.

• Утилиты: packages/core/src/utils/, packages/cli/src/utils/
• Компоненты пользовательского интерфейса: 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/
• Основная логика: указывайте packages/core/, если функциональность не относится конкретно к пользовательскому интерфейсу React.

Отслеживание сторонних зависимостей: если в PR вводится новый импорт для библиотеки утилит (например, lodash.merge, date-fns), отследите, как и где в проекте в настоящее время используется эта библиотека. Скорее всего, уже существует готовый оберточный модуль или общая утилита.

Проверка файлов пакетов: прежде чем отмечать пользовательскую реализацию сложного алгоритма, проверьте файл package.json, чтобы убедиться, не установлена ли уже стандартная библиотека (такая как lodash или uuid), предоставляющая эту функциональность.

3. Изучение кодовой базы (делегирование задач субагентам)

Делегируйте основную работу по исследованию кодовой базы специализированным субагентам. Они оптимизированы для выполнения глубокого поиска и семантического сопоставления без перегрузки истории ваших сеансов.

Чтобы обеспечить всесторонний анализ, вы ДОЛЖНЫ сформулировать очень конкретные задачи для субагентов, предоставив им «зацепки», обнаруженные вами на этапе 1.

• Исследователь кодовой базы: используйте codebase_investigator в качестве основного исследователя. При делегировании сформулируйте задачу, содержащую конкретные исследовательские вопросы о кодовой базе, явно включая следующие векторы поиска:
  • Структурное сходство: Спросите, использует ли существующий код те же базовые API (например: «Использует ли какой-либо существующий код Intl.DateTimeFormat или setTimeout для аналогичных целей?»).
  • Конвенции именования: Спросите, существуют ли символы с похожими шаблонами именования (например: «Есть ли существующие символы с шаблонами именования типа *Format* или *Debounce*?»).
  • Комментарии и документация: спросите, существуют ли ключевые слова из комментариев к PR или JSDoc, описывающие аналогичное поведение в других местах.
  • Соответствие архитектуре: Спросите, где в настоящее время централизована логика данного типа (например: «Где находится централизованная логика форматирования даты?»).
  • Рекомендации по рефакторингу: Очень важно попросить субагента объяснить, как новый код можно рефакторировать, чтобы использовать любую найденную им существующую логику.
• Универсальный агент: Используйте универсального агента для детальных сравнений, требующих большого количества итераций. Например: «Проанализируйте реализацию MyNewComponent в PR и сравните её по смыслу со всеми компонентами в packages/ui/src. Есть ли какие-либо существующие компоненты, которые можно было бы расширить или использовать вместо него?»
• Сохраняйте быстрый путь для простых поисков: для чрезвычайно простых и однозначных проверок (например, «Включает ли package.json lodash?») выполняйте прямой поиск, чтобы сэкономить время. По умолчанию делегируйте любые «исследования» с открытым исходом.

4. Оценка лучших практик

Проверьте, соответствует ли новый код установленным в проекте конвенциям.

• Обработка ошибок: используются ли стандартные для проекта классы ошибок или механизмы ведения журнала?
• Управление состоянием: обходят ли в коде установленные хранилища или контексты?
• Стиль: жестко ли прописаны цвета или интервалы вместо использования переменных темы? Если в PR вводится новый паттерн, сравните его с задокументированными стандартами и явно подтвердите, не следовало ли вместо этого использовать существующий паттерн проекта.

5. Сформулируйте конструктивные замечания

Если вы обнаружили, что PR дублирует существующую функциональность или игнорирует лучшие практики:

• Оставьте чёткий комментарий к ревью.
• Укажите источник: явно укажите абсолютный или относительный по проекту путь к файлу, а также конкретный символ (функцию, компонент, класс), который следует повторно использовать.
• Рекомендации по реализации: предоставьте краткий фрагмент кода или чёткое объяснение, демонстрирующее, как интегрировать существующий код для выполнения требований задачи.
• Объясните преимущества: кратко объясните, почему повторное использование существующего кода выгодно (например, удобство обслуживания, согласованность, встроенная обработка крайних случаев).

Пример комментария:

«Похоже, в этом PR представлена новая утилита formatDate. У нас уже есть надежная и протестированная функция formatDate в файле src/utils/dateHelpers.ts.

Вы можете заменить свою реализацию, импортировав её следующим образом:

import { formatDate } from '../utils/dateHelpers';// Затем используйте её здесь:
const displayDate = formatDate(userDate, 'MMM Do, YYYY');

Использование этой функции гарантирует, что форматирование даты будет согласованным с остальной частью приложения и будет правильно обрабатывать преобразования часовых поясов».