# Ревью с Claude: ловим проблемы до коммита Канонический URL: https://zero2claude.ru/blog/claude-code-review-flow Дата: 2026-09-12 Теги: claude-code, новичкам, ревью кода Перед коммитом стоит спросить Claude: «глянь свежим взглядом, что тут не так». Учимся просить ревью и не принимать его правки вслепую. Код наконец заработал. Ты выдыхаешь, рука тянется к коммиту — и где-то на краю сознания шевелится: «а точно всё? может, я что-то проглядел?» Но смотреть на свой код ещё раз сил уже нет. Глаз замылен, всё кажется нормальным, и проще закоммитить и забыть. А через два дня вылезает баг, которого можно было избежать одним вопросом. Вот про этот вопрос и поговорим. У программистов давно есть привычка — **ревью кода**: прежде чем изменения уйдут в проект, на них смотрит свежий глаз. Раньше для этого нужен был коллега. Теперь свежий взгляд всегда под рукой — это Claude. Он не устал, не замылился, видит весь твой файл целиком и за полминуты подсветит то, мимо чего ты проскочил. ## Зачем вообще показывать код, который и так работает «Работает» и «хорошо» — не одно и то же. Код может делать что нужно прямо сейчас и при этом прятать мину замедленного действия. Свежий взгляд ловит как раз такое — то, что ты не видишь, потому что **слишком хорошо знаешь свой код**. Ты помнишь, что «вот сюда отрицательное число не придёт», а Claude этого не знает и честно спросит: «а если придёт?». Вот что обычно вылавливает ревью, пока ты сам в упор не видишь: - **Забытый случай.** Что будет, если список пустой? А если файла нет? Ты держал в голове удачный сценарий, а про крайний забыл. - **Повтор.** Один и тот же кусок ты скопировал в трёх местах — Claude заметит и предложит свести в одно. - **Имя ни о чём.** Переменная `data2` или функция `process()` — через неделю ты сам не вспомнишь, что это. - **Необработанная ошибка.** Запрос к сети или чтение файла, которые молча падают, вместо того чтобы понятно сказать, что пошло не так. - **Лишняя сложность.** Три вложенных `if` там, где хватило бы одного. Работает, но читать больно. Ничего из этого не ломает код сегодня. Зато каждое аукнется завтра — багом, который тяжело найти, или правкой, на которую уйдёт час вместо минуты. ## Как попросить ревью словами Магия не в Claude, а в формулировке. Если бросить «проверь код», получишь вежливое «выглядит неплохо». Нужно прямо назвать, что ты хочешь свежий взгляд и **только разбор, без правок**. Сравни. Слабо: «посмотри, всё ли тут хорошо». Размыто — и ответ будет такой же размытый. Сильно: > «Сделай ревью этих изменений свежим взглядом, как будто видишь их впервые. Найди потенциальные проблемы: забытые крайние случаи, повторы, непонятные имена, необработанные ошибки. Пока ничего не меняй — просто перечисли, что нашёл, и объясни почему». Разница огромная. Ты задал, **что искать**, и явно сказал **не трогать код**. На выходе — список с объяснениями: вот тут не обработан пустой список, вот эта переменная названа невнятно, вот здесь запрос может упасть. Это не приговор, а карта. Дальше решаешь ты. Раздели ревью и починку на два шага. Сначала проси **только найти и объяснить** проблемы — так ты увидишь весь список и сам решишь, что из этого реально важно, а что можно пока оставить. И лишь потом, по одному пункту, проси исправить. Если сразу сказать «найди и почини всё», Claude перепашет полфайла одной кучей, и ты не разберёшь, что откуда взялось. ## Не принимай правки вслепую Самая опасная ловушка — превратить ревью в кнопку «согласен со всем». Claude разобрал код, предложил исправления, ты бегло киваешь и принимаешь. Так ты просто меняешь свои незамеченные проблемы на чужие — и при этом перестаёшь понимать собственный проект. Ревью имеет смысл, только если ты **остаёшься главным**. Claude — советчик, а не начальник. На каждое замечание полезно задать себе короткий вопрос: - **Это правда проблема или просто другой стиль?** Иногда «улучшение» — дело вкуса, а не баг. Не обязан соглашаться. - **Я понял, что меняется?** Если предложенная правка тебе непонятна — не принимай молча. Попроси: «объясни простыми словами, что эта правка меняет и зачем». - **Я проверил после?** Любую принятую правку прогони — тестами или руками. Свежий взгляд тоже ошибается. Когда правок несколько, бери их по одной: одна правка → проверка → следующая. Так при поломке сразу ясно, кто виноват. И каждый удачный шаг сохраняй коммитом — тогда любой неудачный следующий откатывается одной командой. Кстати, читать предлагаемые изменения «было/стало» мы подробно разбирали в посте [про diff](/blog/read-a-diff) — без этого навыка ревью превращается в угадайку. Claude уверенно объяснит даже то, в чём ошибается. Если он говорит «здесь баг» — не верь на слово, попроси показать конкретный сценарий, при котором всё ломается. Нет внятного сценария — возможно, и проблемы нет. Свежий взгляд ценен, но финальное «да» всегда за тобой. ## Сделай это привычкой Ревью — не лишний шаг, а та самая пауза, которая отделяет «вроде работает» от «я уверен». И она почти ничего не стоит: один вопрос Claude перед коммитом, минута на список, ещё минута — решить, что из него важно. Заведи себе простой ритм: дописал кусок → попросил свежий взгляд → разобрал замечания по одному → проверил → закоммитил. Сначала это будет казаться формальностью. А потом ты поймаешь первый баг до того, как он попал в проект, — и больше не захочешь коммитить без этой проверки. Если хочешь освоить весь этот цикл — терминал, Git, коммиты и работу с Claude Code — с нуля и на практике, у нас есть бесплатный курс ровно про это, с тренажёром прямо в браузере.