Код наконец заработал. Ты выдыхаешь, рука тянется к коммиту — и где-то на краю сознания шевелится: «а точно всё? может, я что-то проглядел?» Но смотреть на свой код ещё раз сил уже нет. Глаз замылен, всё кажется нормальным, и проще закоммитить и забыть. А через два дня вылезает баг, которого можно было избежать одним вопросом.
Вот про этот вопрос и поговорим. У программистов давно есть привычка — ревью кода: прежде чем изменения уйдут в проект, на них смотрит свежий глаз. Раньше для этого нужен был коллега. Теперь свежий взгляд всегда под рукой — это Claude. Он не устал, не замылился, видит весь твой файл целиком и за полминуты подсветит то, мимо чего ты проскочил.
Зачем вообще показывать код, который и так работает
«Работает» и «хорошо» — не одно и то же. Код может делать что нужно прямо сейчас и при этом прятать мину замедленного действия. Свежий взгляд ловит как раз такое — то, что ты не видишь, потому что слишком хорошо знаешь свой код. Ты помнишь, что «вот сюда отрицательное число не придёт», а Claude этого не знает и честно спросит: «а если придёт?».
Вот что обычно вылавливает ревью, пока ты сам в упор не видишь:
- Забытый случай. Что будет, если список пустой? А если файла нет? Ты держал в голове удачный сценарий, а про крайний забыл.
- Повтор. Один и тот же кусок ты скопировал в трёх местах — Claude заметит и предложит свести в одно.
- Имя ни о чём. Переменная
data2или функцияprocess()— через неделю ты сам не вспомнишь, что это. - Необработанная ошибка. Запрос к сети или чтение файла, которые молча падают, вместо того чтобы понятно сказать, что пошло не так.
- Лишняя сложность. Три вложенных
ifтам, где хватило бы одного. Работает, но читать больно.
Ничего из этого не ломает код сегодня. Зато каждое аукнется завтра — багом, который тяжело найти, или правкой, на которую уйдёт час вместо минуты.
Как попросить ревью словами
Магия не в Claude, а в формулировке. Если бросить «проверь код», получишь вежливое «выглядит неплохо». Нужно прямо назвать, что ты хочешь свежий взгляд и только разбор, без правок. Сравни.
Слабо: «посмотри, всё ли тут хорошо». Размыто — и ответ будет такой же размытый.
Сильно:
«Сделай ревью этих изменений свежим взглядом, как будто видишь их впервые. Найди потенциальные проблемы: забытые крайние случаи, повторы, непонятные имена, необработанные ошибки. Пока ничего не меняй — просто перечисли, что нашёл, и объясни почему».
Разница огромная. Ты задал, что искать, и явно сказал не трогать код. На выходе — список с объяснениями: вот тут не обработан пустой список, вот эта переменная названа невнятно, вот здесь запрос может упасть. Это не приговор, а карта. Дальше решаешь ты.
Совет
Раздели ревью и починку на два шага. Сначала проси только найти и объяснить проблемы — так ты увидишь весь список и сам решишь, что из этого реально важно, а что можно пока оставить. И лишь потом, по одному пункту, проси исправить. Если сразу сказать «найди и почини всё», Claude перепашет полфайла одной кучей, и ты не разберёшь, что откуда взялось.
Не принимай правки вслепую
Самая опасная ловушка — превратить ревью в кнопку «согласен со всем». Claude разобрал код, предложил исправления, ты бегло киваешь и принимаешь. Так ты просто меняешь свои незамеченные проблемы на чужие — и при этом перестаёшь понимать собственный проект.
Ревью имеет смысл, только если ты остаёшься главным. Claude — советчик, а не начальник. На каждое замечание полезно задать себе короткий вопрос:
- Это правда проблема или просто другой стиль? Иногда «улучшение» — дело вкуса, а не баг. Не обязан соглашаться.
- Я понял, что меняется? Если предложенная правка тебе непонятна — не принимай молча. Попроси: «объясни простыми словами, что эта правка меняет и зачем».
- Я проверил после? Любую принятую правку прогони — тестами или руками. Свежий взгляд тоже ошибается.
Когда правок несколько, бери их по одной: одна правка → проверка → следующая. Так при поломке сразу ясно, кто виноват. И каждый удачный шаг сохраняй коммитом — тогда любой неудачный следующий откатывается одной командой. Кстати, читать предлагаемые изменения «было/стало» мы подробно разбирали в посте про diff — без этого навыка ревью превращается в угадайку.
Важно
Claude уверенно объяснит даже то, в чём ошибается. Если он говорит «здесь баг» — не верь на слово, попроси показать конкретный сценарий, при котором всё ломается. Нет внятного сценария — возможно, и проблемы нет. Свежий взгляд ценен, но финальное «да» всегда за тобой.
Сделай это привычкой
Ревью — не лишний шаг, а та самая пауза, которая отделяет «вроде работает» от «я уверен». И она почти ничего не стоит: один вопрос Claude перед коммитом, минута на список, ещё минута — решить, что из него важно.
Заведи себе простой ритм: дописал кусок → попросил свежий взгляд → разобрал замечания по одному → проверил → закоммитил. Сначала это будет казаться формальностью. А потом ты поймаешь первый баг до того, как он попал в проект, — и больше не захочешь коммитить без этой проверки.
Если хочешь освоить весь этот цикл — терминал, Git, коммиты и работу с Claude Code — с нуля и на практике, у нас есть бесплатный курс ровно про это, с тренажёром прямо в браузере.