Как организован процесс исправления бага (bug fix) в вашей команде?

А, слушай, про баги! Ну классика жанра, вечный цирк с конями. Сейчас расскажу, как это у нормальных людей делается, а не как у нас обычно — «нашел, херакнул костыль, закоммитил в мастер, ушел пить чай, а потом вся система легла, и все охуели».

В общем, чтобы не было потом мучительно больно и стыдно, есть там, понимаешь, целый ритуал, этакий священный танец с бубном вокруг глюка.

Вот как это по-человечьи должно выглядеть:

1. Поймал жука — запиши его, сука! Первым делом — не орать «всё ебнулось!», а тихо, по-английски, завести ему домик в вашей системе — Jira там, GitHub Issues. И описать всё так, чтобы любой идиот (вроде меня) мог это повторить: что тыкнул, что должно было вылезти, а что вылезло на самом деле (желательно со скрином, где красненьким обведено). Окружение, логи — всё в студию. Без этого — нихуя не баг, а твои фантазии.

2. Оценка ущерба: пиздец или так, мелочь? Потом подходит менеджер или тимлид, смотрит на эту хуйню и решает: «О, это пиздец, пользователи не могут платить» — значит, срочно, «А, это кнопка на полпикселя съехала в браузере IE6» — значит, можно и подождать, пусть полежит в бэклоге, там ей и место.

3. Время хирурга-разработчика. Вот тут начинается магия. Берешь здоровую основную ветку (main, master) и отпочковываешься. Ветку называешь внятно, например, fix/login-null-pointer, а не super-puper-fix-228. Потом садишься ищешь, где же эта манда с ушами спряталась. Нашел причину — исправляешь минимально необходимым изменением. Не надо тут рефакторить полпроекта и прикручивать блокчейн. И вот тут, внимание, САМОЕ ВАЖНОЕ, БЛЯДЬ! Написал или обновил тест, который этот самый баг и ловит. Чтобы он прямо падал, если вдруг эта хрень вернется. Это называется «застраховаться от регрессии», или «не быть мудаком в будущем».

   // Смотри, типа вот так. Раньше тут на null ругался, а теперь цивилизованно исключение кидает.
   @Test
   void login_shouldHandleNullUsernameGracefully() {
       // Раньше здесь был NullPointerException
       assertThatThrownBy(() -> authService.login(null, "pass"))
           .isInstanceOf(InvalidCredentialsException.class);
   }

4. Парад крошек: Code Review. Залил свои правки в Pull Request (или Merge Request) и зовешь коллегу: «Васян, глянь, не насрал ли я мимо унитаза?». Васян обязан проверить: а правильный ли это фикс? А тесты есть? А стиль кода не кривой? А случайно я не сломал чего-то другого своим костылем? Без этого шага — никак. Иначе получится «один пишет, двое исправляют».

5. Большой брат следит: CI/CD. Как только Васян сказал «ок» и нажал кнопку approve, твоя ветка летит мержиться в основную. И тут же срабатывает автоматический пайплайн — всё собирается заново и гоняет все тесты, все до одного. Если что-то пошло не так — всё, приехали, мерж не пройдет. Система не даст наговнить в общий код.

6. Проверка на кошках. Если баг был серьезный, то после успешного мержа его тащат на тестовый стенд (staging) и руками тыкают: «Ну что, теперь не падает? Не вылезает ли прежняя хуйня?». Иногда этим занимается QA, иногда сами разработчики.

7. Выпускаем зверя. Если всё ок — фикс попадает в продакшен. Иногда в составе очередного релиза, иногда отдельным хотфиксом, если совсем пиздец был.

8. Точка. Задача в трекере закрывается. Если баг был эпичный, системный — можно провести разбор полетов (post-mortem), чтобы понять, как так вышло и как не допустить этого в будущем. Но обычно всем похуй, все уже бегут тушить следующий пожар.

А главная мысль, ёпта, вот какая: каждое исправление — это как операция. Её нужно делать в стерильных условиях (отдельная ветка), с контролем (ревью), и обязательно оставить шов, который потом покажет, если рана разойдется снова (тест). И тогда жить станет проще, а волнение ебать — меньше.