Как защитить рефакторинг, который назвали «нейрослопом»

🧩 Что случилось

Участник Гильдии несколько недель рефакторил экран: обновил дизайн, подключил новое API, исправил старые баги, добавил тесты и документацию.

Получилось два больших MR. В первом — 3200 новых строк и 1800 удалённых. Из добавленных строк 1700 приходились на тесты, ещё 200 — на документацию.

Рефакторинг согласовали заранее. Участник обозначил риски, но во время работы они не реализовались. Казалось, задачу можно заканчивать.

На ревью сразу нашли необработанное исключение. После этого начался шквал критики. Поскольку часть работы участник делал с AI, код назвали «нейрослопом», а оба MR предложили закрыть.

Участник пришёл в технический чат Гильдии с вопросом:

«Я потратил кучу времени, чтобы превратить спроектированный нейронкой код в задокументированный, структурированный и разбитый по небольшим файлам. В чём я не прав?»

🔍 Что разобрали в Гильдии

В обсуждении отделили две проблемы.

Первая — техническая. В одном изменении соединились рефакторинг, новое API, новый дизайн и исправление старых багов. Такой MR трудно проверить, даже если большая часть новых строк — тесты и документация.

Вторая — переговорная. Предварительное согласование задачи не гарантирует, что результат примут. Право на финальное решение всё равно остаётся у лида.

Участнику предложили не доказывать, что код хороший, а задать два вопроса:

— Что конкретно не устраивает в текущем решении?
— Что можно исправить, чтобы продолжить ревью?

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

✅ Чем всё закончилось

Через два дня участник вернулся с результатом.

MR решили влить для релиза. Затем изменения откатят и внесут заново небольшими частями. Участник дополнительно проверит код, исправит неточности и перепишет документацию по принципу «человек для человека».

На будущее команда договорилась разбивать MR объёмом больше 500 строк.

Это не победа разработчика над ревьюером. Ошибка в коде была, а большой MR действительно усложнил проверку.

Но работу не выбросили. Вместо «закрываем всё» появился план, с которым согласилась команда.

Когда варишься в ситуации один, критика кода быстро начинает звучать как оценка твоего профессионального уровня. Здесь помог взгляд инженеров, которые не участвовали в конфликте: они показали, где проблема в коде, где — в процессе, а где — в самом разговоре.

💬 Если вы тоже хотя бы раз приносили на ревью огромный MR, а потом жалели об этом, поставьте реакцию. Посмотрим, сколько нас таких.

🎙 Послезавтра, в субботу, — открытый стрим Тимура: «AI: зачем нужны структуры данных для JavaScript — практические примеры для бэкенда и фронтенда»

Приходите.

⏳ P. S. Осталось три полных дня — 31 июля, 1 и 2 августа, — чтобы попасть в закрытую Гильдию NextTick.

👉 Узнать, что внутри Гильдии