Что такое регрессия — и почему починенный баг возвращается

Смотри, обидная штука. Есть баг, который ты уже чинил. Неделю назад. Ты помнишь, как мучился, помнишь строчку, которую поправил. А он снова здесь.

И вот что важно: это не «баг вернулся сам». Его вернули. Почти всегда — правкой в соседнем месте, которую делал человек, не знавший, что тут уже воевали.

У этого есть название — регрессия. И это единственный вид бага, который честно говорит тебе кое-что о проекте.

Что такое регрессия простыми словами

Регрессия — это когда работавшее перестало работать после изменения.

Не новая функция сломалась. Сломалась старая, которую ты не трогал.

Разница принципиальная:

• Обычный баг — ты написал что-то новое, и оно кривое. Нормально, так бывает у всех.
• Регрессия — ты написал что-то новое вон там, а отвалилось вот здесь. Ты даже не смотрел в эту сторону.

Слово пришло из статистики и означает «движение назад». Тут смысл буквальный: проект откатился в состояние, из которого ты его уже вытаскивал.

Почему баг возвращается

Причина почти всегда одна: починка жила только в коде, а не в проверке.

Представь. Ты нашёл, что приложение падает на пустом списке. Дописал проверку «если список пустой — ничего не делай». Готово, работает.

Проходит месяц. Ты (или агент) наводишь порядок в этом файле. Видишь странную проверку на пустоту — вроде лишняя, список же всегда приходит с сервера. Убираешь. Чище стало.

Падение вернулось.

И заметь: тот, кто убрал проверку, вёл себя разумно. Код не объяснял, зачем он такой. Причина починки осталась у тебя в голове, а голова — плохое хранилище.

Вот это и есть главное свойство регрессии: она не про невнимательность. Она про то, что знание не было записано туда, где его прочитают.

Почему ИИ-агент приносит регрессии чаще

Тут стоит быть честным. Агент не «хуже» человека — у него просто другая слепая зона.

Он видит кусок кода, который ему показали. И он очень хочет сделать его красивее. Странная проверка на пустоту, непонятный if, костыль без комментария — всё это выглядит как мусор, который надо убрать. Агент не знает, что три месяца назад этот костыль спас продакшн.

Плюс он часто правит больше, чем ты просил. Попросил поменять текст кнопки — заодно «улучшил» функцию рядом. Про это отдельно стоит почитать: почему в коде от ИИ появляются баги.

Отсюда простое правило: чем быстрее пишется код, тем дороже стоит отсутствие проверок. Скорость без сетки — это просто более быстрое падение.

Как поймать регрессию один раз и навсегда

Ход ровно один, и он дешевле, чем кажется.

Когда чинишь баг — сначала напиши проверку, которая падает. Потом чини.

По шагам это выглядит так:

1. Ты воспроизвёл баг руками. Приложение падает на пустом списке.
2. Ты пишешь тест: «дай пустой список — приложение не падает». Запускаешь. Он красный. Это важно: красный тест доказывает, что он вообще ловит именно эту проблему.
3. Чинишь код.
4. Запускаешь снова. Зелёный.

Теперь эта починка живёт не у тебя в голове, а в репозитории. Если кто-нибудь — ты, коллега или агент — уберёт проверку, тест покраснеет и скажет почему.

Такие тесты называют регрессионными. Они не проверяют «работает ли приложение вообще». Они охраняют конкретные места, где уже было больно.

Два усилителя к этому:

• Оставь записку в коде. Одна строка комментария «без этой проверки падает на пустом списке, см. баг от 12 марта» экономит чужой час и спасает костыль от удаления.
• Пусть тесты гоняет робот. Тест, который запускают раз в месяц, — это не сетка. Про то, как повесить их на каждый коммит, есть отдельный разбор: что такое CI/CD. Сам тест, кстати, вполне можно попросить написать модель — как это делать.

И финальная мысль, ради которой всё это. Регрессия — неприятный, но полезный сигнал. Она не говорит «ты плохо кодишь». Она говорит: вот место, где твой проект держится на памяти, а не на проверках. Каждая пойманная регрессия — это одна дырка в сетке, которую ты закрыл навсегда.

Чем регрессия отличается от обычного бага?

Обычный баг — в новом коде, который ты только что написал. Регрессия — в старом коде, который работал до твоей правки и сломался из-за неё. Второе опаснее: его никто не ищет, потому что «эта часть же давно работает».

Нужны ли регрессионные тесты, если проект маленький?

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

Кто виноват в регрессии — тот, кто сломал?

Чаще всего никто. Человек или агент правил код, который не объяснял сам себя. Виновата не правка, а отсутствие проверки, которая бы эту правку остановила.