Опытный разработчик смотрит на чужой код полминуты и говорит: тут что-то не так. Джун спрашивает — как ты это понял? И сеньор зависает. Именно так звучит заголовок обсуждения на dev.to: «A junior asked me how I knew the code was wrong. I couldn't answer him». Секрета тут нет — объяснения в голове действительно нет. Есть ощущение, и всё.
Ситуация неприятная для обеих сторон. Джун уходит с мыслью, что опыт — это что-то мистическое и недостижимое. Наставник чувствует себя самозванцем: вроде проблему видит, а сформулировать не может. Между тем за «чутьём» стоит вполне разбираемый механизм.
Интуиция — это узнавание, а не ясновидение
Мозг не выводит логику бага с нуля каждый раз. Он сравнивает увиденное с накопленными шаблонами: вот так выглядит код, который сломается на пустом списке; вот так — функция, тихо глотающая ошибку. Тысячи просмотренных ревью превращаются в набор узнаваемых картинок. Срабатывание занимает доли секунды, а путь до него — годы.
Отсюда и провал в разговоре. Узнавание идёт быстро и без слов, а объяснение требует развернуть картинку обратно в рассуждение. Это отдельный навык, и он тренируется.
Что на самом деле цепляет взгляд
- Имя расходится с делом. Функция называется проверкой, а внутри пишет в базу или шлёт запрос наружу. Читатель верит названию и перестаёт проверять содержимое — так и рождаются сюрпризы в продакшене.
- Код трудно протестировать. Чтобы проверить одну функцию, приходится поднимать полприложения, подменять глобальное состояние или ждать таймер. Обычно это сигнал, что границу между частями провели не там.
- Ошибка гасится молча. Пустой блок catch или заглушка, возвращающая значение по умолчанию. Само по себе не баг, но именно здесь баги потом живут месяцами, потому что о них никто не узнаёт.
- Функция трогает то, что ей не принадлежит: растёт связанность, а область видимости разъезжается.
- Ветвление по флагу. Если поведение разъезжается по if внутри одного метода, скорее всего тут спрятались две разные задачи.
- Код работает случайно. Проверка проходит, но объяснить почему — не получается.
Как превратить ощущение в комментарий
Самое полезное, что может сделать наставник, — описать сценарий вместо вердикта. Формулировка «мне не нравится» бесполезна. Формулировка «на пустом списке это упадёт» проверяема, с ней можно спорить и её можно проверить тестом.
Практический приём: когда ловите себя на «здесь что-то не так», задайте себе два вопроса. Чего я ожидал увидеть на этом месте? При каком входе это сломается? Если второй вопрос ответа не даёт, возможно, у вас претензия к стилю.
Что писать в ревью
- Что именно насторожило: строка, имя, отсутствие проверки.
- Сценарий, при котором это станет проблемой.
- Проверку, которую можно написать прямо сейчас, чтобы спор закрылся.
- Что остаётся на усмотрение автора — это тоже полезно обозначить.
Когда интуиция ошибается
Она обучена на вашем опыте, поэтому в незнакомом контексте даёт ложные срабатывания. Непривычная парадигма после десяти лет ООП выглядит подозрительно вся. Легаси с чужой логикой кажется неправильным просто потому, что причины не видны. Скрипт миграции бывает нарочно уродливым.
И отдельно: некрасивый код и неправильный код — разные вещи. Претензия к форматированию и претензия к сценарию падения требуют разных аргументов. Смешивать их в одном комментарии — верный способ поссориться с автором.
Интуиция против явного правила
| Критерий | Интуиция | Явное правило |
|---|---|---|
| Скорость | Срабатывает за секунды, без усилий | Требует чтения и проверки |
| Основа | Накопленные примеры | Линтер, чек-лист, тест |
| Когда работает | В знакомом стеке и типовой задаче | В любом контексте, включая незнакомый |
| Когда ломается | Новый стек, чужая логика, сгенерированный код | Не покрывает то, чего нет в чек-листе |
| Передача другому | Почти не передаётся напрямую | Копируется словами и кодом |
| Ложное срабатывание | Частое, цена — лишний спор | Редкое, но правило устаревает |
Как это тренировать
- Перед запуском кода предскажите результат — включая случай, который кажется маловероятным. Расхождение прогноза и факта и есть ваш урок.
- Разбирайте чужие ревью. Именно чужие: там видно, какие сигналы замечают другие люди.
- Вернитесь к своим старым багам и спросите: был ли сигнал виден заранее в диффе?
- Ведите короткий список «запахов» своими словами. Через полгода он превратится в личный чек-лист.
При чём здесь ИИ
Генерация кода ускорилась, и узким местом стало ревью. Модели выдают код, который выглядит знакомо — ровно то, на что реагирует интуиция. Правдоподобный текст проходит «взгляд эксперта» легче, чем заслуживает.
Отсюда практический вывод. Просите модель назвать паттерн, который вы унюхали: «как это называется», «какие входы не покрыты», «что тут может упасть». Иногда она сформулирует то, на что у вас не хватило слов. Решение всё равно за вами: модель не видит ни вашего легаси, ни договорённостей внутри команды.
Ощущение — это сжатое правило, которое вы пока не развернули словами.
Что делать дальше
Если вы наставник — на следующем ревью проговорите вслух, что именно вас насторожило, даже если мысль сырая. Это ценнее готового вердикта: джун подхватит сам способ смотреть.
Если вы джун — задавайте вопрос «при каком входе это сломается». Он вытягивает из наставника объяснение быстрее, чем «почему это плохо», и заодно учит вас проверять чужие доводы.
Интуиция не появляется от чтения статей про чистый код. Она собирается из разобранных расхождений между тем, что вы ожидали, и тем, что произошло.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.