Топ-10 промптов для ревью и рефакторинга кода

<p>AI может ускорить ревью и подготовку рефакторинга, но не заменяет инженера, тесты и знание контекста продукта. Ниже — 10 прикладных промптов для ситуаций, где важно не просто «сделать код красивее», а сохранить поведение, увидеть риски и получить проверяемый план изменений.</p><h2>Как пользоваться подборкой</h2><p>Перед отправкой промпта дайте модели минимальный контекст: язык, версию фреймворка, цель изменения, ограничения, фрагмент кода и связанные тесты. Просите не переписывать всё сразу, а сначала перечислять риски, предположения и вопросы. Вывод модели требует человеческого ревью и зависит от модели, полноты входных данных и качества самого кода.</p><h2>Таблица выбора промпта</h2><table><thead><tr><th>Задача</th><th>Подходящий промпт</th><th>Главный результат</th></tr></thead><tbody><tr><td>Быстрое ревью PR</td><td>1</td><td>Список замечаний по приоритету</td></tr><tr><td>Архитектурные риски</td><td>2</td><td>Границы модулей и зависимости</td></tr><tr><td>Безопасный рефакторинг</td><td>3, 4</td><td>План маленьких шагов</td></tr><tr><td>Читаемость</td><td>5, 6</td><td>Упрощение имён и ветвлений</td></tr><tr><td>Безопасность и регрессии</td><td>7, 8, 9</td><td>Угрозы, тесты, edge cases</td></tr><tr><td>Финальная проверка</td><td>10</td><td>Чеклист перед merge</td></tr></tbody></table><h2>Промпты для ревью</h2><h3>Промпт 1</h3><p><strong>Когда использовать:</strong> перед первым проходом по pull request. <strong>Переменные:</strong> <code>{language}</code>, <code>{diff}</code>, <code>{goal}</code>. <strong>Ожидаемый вывод:</strong> замечания с приоритетами, рисками и предложениями. <strong>Проверка качества:</strong> каждое замечание ссылается на конкретный фрагмент. <strong>Частая ошибка:</strong> модель спорит о стиле вместо влияния на поведение.</p><blockquote><code>Ты опытный ревьюер {language}. Проверь diff: {diff}. Цель изменения: {goal}. Раздели вывод на Critical, Major, Minor. Для каждого пункта укажи риск, почему это важно, минимальное исправление и вопрос автору, если контекста не хватает. Не придумывай требования.</code></blockquote><h3>Промпт 2</h3><p><strong>Когда использовать:</strong> если изменение затрагивает слои, модули или публичные интерфейсы. <strong>Переменные:</strong> <code>{architecture}</code>, <code>{code}</code>, <code>{constraints}</code>. <strong>Ожидаемый вывод:</strong> карта зависимостей и архитектурные запахи. <strong>Проверка качества:</strong> рекомендации не требуют полной переписи. <strong>Частая ошибка:</strong> модель предлагает абстракции без измеримой пользы.</p><blockquote><code>Оцени архитектуру фрагмента: {code}. Контекст системы: {architecture}. Ограничения: {constraints}. Найди нарушения границ ответственности, лишние зависимости, скрытые сайд-эффекты и точки роста сложности. Предложи 3 варианта: минимальный, умеренный, долгосрочный.</code></blockquote><h3>Промпт 3</h3><p><strong>Когда использовать:</strong> перед рефакторингом устаревшего или хрупкого кода. <strong>Переменные:</strong> <code>{code}</code>, <code>{tests}</code>, <code>{risk_tolerance}</code>. <strong>Ожидаемый вывод:</strong> последовательность безопасных шагов. <strong>Проверка качества:</strong> каждый шаг можно закоммитить отдельно. <strong>Частая ошибка:</strong> модель сразу выдаёт большой переписанный блок.</p><blockquote><code>Составь план безопасного рефакторинга для {code}. Имеющиеся тесты: {tests}. Допустимый риск: {risk_tolerance}. Не меняй поведение. Дай шаги малыми коммитами: что изменить, какие тесты запустить, как откатить, какой сигнал покажет регрессию.</code></blockquote><h3>Промпт 4</h3><p><strong>Когда использовать:</strong> когда нужно отделить чистую логику от ввода-вывода. <strong>Переменные:</strong> <code>{code}</code>, <code>{side_effects}</code>, <code>{framework}</code>. <strong>Ожидаемый вывод:</strong> план выделения функций и адаптеров. <strong>Проверка качества:</strong> публичный контракт остаётся прежним. <strong>Частая ошибка:</strong> модель игнорирует транзакции, кэш или порядок вызовов.</p><blockquote><code>Проанализируй {code} во фреймворке {framework}. Сайд-эффекты: {side_effects}. Предложи, как отделить бизнес-логику от I/O без изменения внешнего поведения. Укажи новые функции, их входы и выходы, места для моков и тестов.</code></blockquote><h3>Промпт 5</h3><p><strong>Когда использовать:</strong> если код работает, но его тяжело читать. <strong>Переменные:</strong> <code>{code}</code>, <code>{team_style}</code>. <strong>Ожидаемый вывод:</strong> предложения по именам, структуре и удалению шума. <strong>Проверка качества:</strong> улучшение понятно без знания вкусов автора. <strong>Частая ошибка:</strong> косметические правки маскируются под рефакторинг.</p><blockquote><code>Улучши читаемость {code} с учётом стиля команды: {team_style}. Не меняй алгоритм. Предложи переименования, разбиение длинных выражений, удаление дублирования и комментарии только там, где код сам себя не объясняет. Верни список изменений и обновлённый фрагмент.</code></blockquote><h3>Промпт 6</h3><p><strong>Когда использовать:</strong> при сложных условиях, вложенных if или switch. <strong>Переменные:</strong> <code>{code}</code>, <code>{domain_rules}</code>. <strong>Ожидаемый вывод:</strong> упрощённая логика с сохранением правил. <strong>Проверка качества:</strong> все ветки исходного поведения перечислены. <strong>Частая ошибка:</strong> модель теряет пограничное условие.</p><blockquote><code>Разбери условную логику в {code}. Доменные правила: {domain_rules}. Сначала составь таблицу веток и исходов, затем предложи упрощение: guard clauses, таблица решений или полиморфизм. Отметь, какие случаи требуют тестов перед изменением.</code></blockquote><h3>Промпт 7</h3><p><strong>Когда использовать:</strong> для поиска уязвимостей в изменённом коде. <strong>Переменные:</strong> <code>{code}</code>, <code>{threat_model}</code>, <code>{data_sources}</code>. <strong>Ожидаемый вывод:</strong> потенциальные угрозы и способы проверки. <strong>Проверка качества:</strong> нет голословных обвинений без сценария атаки. <strong>Частая ошибка:</strong> модель путает теоретический риск с реальной эксплуатацией.</p><blockquote><code>Проведи security review кода: {code}. Модель угроз: {threat_model}. Источники данных: {data_sources}. Найди риски инъекций, утечек, ошибок авторизации, небезопасной сериализации и логирования секретов. Для каждого риска дай сценарий, вероятность, влияние и безопасное исправление.</code></blockquote><h3>Промпт 8</h3><p><strong>Когда использовать:</strong> когда нужен набор тестов перед изменениями. <strong>Переменные:</strong> <code>{code}</code>, <code>{test_framework}</code>, <code>{known_bugs}</code>. <strong>Ожидаемый вывод:</strong> список тест-кейсов и приоритетов. <strong>Проверка качества:</strong> тесты проверяют поведение, а не реализацию. <strong>Частая ошибка:</strong> модель генерирует тесты, которые повторяют текущие ошибки.</p><blockquote><code>Для {code} предложи тесты в стиле {test_framework}. Известные баги: {known_bugs}. Сначала опиши наблюдаемое поведение и инварианты, затем happy path, edge cases, ошибки входных данных и регрессионные тесты. Не опирайся на приватные методы, если можно тестировать публичный контракт.</code></blockquote><h3>Промпт 9</h3><p><strong>Когда использовать:</strong> при работе с производительностью без преждевременной оптимизации. <strong>Переменные:</strong> <code>{code}</code>, <code>{load_profile}</code>, <code>{metrics}</code>. <strong>Ожидаемый вывод:</strong> гипотезы, измерения и осторожные улучшения. <strong>Проверка качества:</strong> есть план бенчмарка до изменения. <strong>Частая ошибка:</strong> модель предлагает микрооптимизации без данных.</p><blockquote><code>Оцени производительность {code}. Профиль нагрузки: {load_profile}. Доступные метрики: {metrics}. Не делай выводов без измерений. Назови вероятные узкие места, как их подтвердить, какие изменения безопасны, а какие требуют нагрузочного теста.</code></blockquote><h3>Промпт 10</h3><p><strong>Когда использовать:</strong> перед merge после правок. <strong>Переменные:</strong> <code>{diff}</code>, <code>{tests_run}</code>, <code>{release_context}</code>. <strong>Ожидаемый вывод:</strong> финальный список блокеров и остаточных рисков. <strong>Проверка качества:</strong> модель явно говорит, где ей не хватает данных. <strong>Частая ошибка:</strong> финальная проверка превращается в формальное «всё хорошо».</p><blockquote><code>Сделай финальное ревью перед merge. Diff: {diff}. Запущенные тесты: {tests_run}. Контекст релиза: {release_context}. Проверь поведение, обратную совместимость, миграции, конфиги, логи, observability и план отката. Верни: блокеры, желательные улучшения, остаточные риски, вопросы к человеку.</code></blockquote><h2>Как встроить в рабочий процесс</h2><p>Лучше использовать эти промпты не вместо code review, а как предварительный слой. Автор может прогнать промпты 3, 5 и 8 до открытия PR, ревьюер — 1, 2 и 7 во время проверки, тимлид — 10 перед рискованным merge. Если вывод модели противоречит тестам, документации или доменным правилам, приоритет остаётся за проверяемыми источниками и решением команды.</p><h2>Чеклист запуска</h2><ul><li>Укажите язык, версии библиотек и цель изменения.</li><li>Добавьте diff, а не только итоговый файл, если нужен обзор PR.</li><li>Попросите модель разделять факты, предположения и вопросы.</li><li>Не применяйте патчи без локального запуска тестов и ручного ревью.</li><li>Фиксируйте спорные решения в комментариях PR или ADR.</li></ul><h2>FAQ</h2><p><strong>Можно ли доверять найденным ошибкам?</strong> Нет без проверки. AI помогает заметить риск, но может ошибиться, пропустить контекст или предложить неверное исправление.</p><p><strong>Что отправлять модели: весь проект или фрагмент?</strong> Начинайте с diff, интерфейсов, тестов и краткого описания архитектуры. Весь проект редко нужен и повышает шум.</p><p><strong>Нужно ли просить модель сразу переписать код?</strong> Обычно нет. Безопаснее сначала получить план, риски и тесты, а затем менять код маленькими шагами.</p><h2>Источники и ограничения</h2><p>При подготовке учитывались общие рекомендации по формулированию запросов и проверке результатов: <a href="https://help.openai.com/en/articles/10032626-prompt-engineering-best-practices-for-chatgpt">OpenAI prompt engineering best practices</a>, <a href="https://zapier.com/blog/ai-prompt-templates/">Zapier AI prompt templates</a>, <a href="https://help.zapier.com/hc/en-us/articles/36532133250317-How-to-prompt-AI-in-Zapier-products">Zapier guide to prompting</a>. Это не универсальный стандарт ревью: качество ответа зависит от модели, входных данных, контекста проекта и формулировки задачи. Любой AI-вывод требует человеческой проверки, тестирования и оценки безопасности.</p>