Даже самый аккуратный разработчик однажды оставляет после себя баг. Иногда это мелочь, иногда — баги становятся фичами или мемами, иногда — поводом для бессонных ночей. Как баг появляется, кто и как его находит, почему некоторые баги живут дольше некоторых стартапов и что с ними делать — разберём по шагам.

🔍 Стадия 1. Зародыш: баг появляется (или нет)

Баги рождаются по-разному. Иногда это банальная опечатка. Иногда — кривой if, который сломал логику. Иногда баги — это побочка спешки или компромиссов. Разработчик мог что-то не предусмотреть или тестировщик проглядел редкий кейс.

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

📣 Стадия 2. Кто-то сообщил

Дальше багу везёт или не везёт: кто-то пишет багрепорт. Это может быть юзер, коллега, QA или даже ты сам. Часто первый сигнал — это что-то вроде:

«У меня всё сломалось».

Половина таких «багов» — это баги пользователя (он что-то не так сделал) или недоработанный UX. Если человеку непонятно, как что-то работает, он решает, что баг.

✅ Стадия 3. Подтверждение или отклонение

Если багрепорт вменяемый — его проверяют. Тут баг может умереть сразу:

  • «Не воспроизводится».
  • «Работает, как задумано».
  • «Это фича, а не баг».

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

⚙️ Стадия 4. Приоритизация и план

Открытых багов может быть сотни. Сразу чинить все — невозможно. Поэтому багам ставят приоритет:

  • 🔥 Блокер — всё горит, сайт лежит, пользователи страдают. Чинить немедленно.
  • ⚡ Критический — мешает работать ключевому функционалу.
  • 🐛 Майнор — некритично, но неприятно.
  • 🧹 Тривиал — ну, кто-то заметил опечатку.

Приоритет решает, когда баг дойдёт до рук разработчика. Горячие баги попадают в хотфиксы, остальное уходит в бэклог и ждёт часа.

🔧 Стадия 5. Исправление

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

Исправил — делаешь коммит, пушишь, добавляешь ссылку на баг. Всё. Баг переходит в статус «Исправлен».

✅ Стадия 6. Проверка и закрытие

Исправленный баг идёт на тест. QA или автор багрепорта проверяет:

  • баг больше не воспроизводится?
  • ничего не сломалось по цепочке?

Если всё ок — баг закрывается. Он мёртв. Если нет — он переоткрывается и весь цикл повторяется.

🔄 А что потом?

Иногда баги «воскресают» через месяцы. Чаще всего — если фиксят симптом, а не причину. Или если баг был в одной ветке, а кто-то закатил старый код обратно.

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

👀 Почему баги живут долго?

  • Менеджеры забили или не приоритизировали.
  • Баг сложно воспроизвести.
  • Баг не критичный — бизнесу норм.
  • Исправить баг дороже, чем жить с ним.

🔑 Как сделать баги управляемыми

1️⃣ Вводи нормальную баг-трекинг систему (Jira, GitLab Issues — что угодно).
2️⃣ Требуй адекватные багрепорты: скрины, логи, шаги воспроизведения.
3️⃣ Не закрывай баги «на глаз». Проверяй фиксы и смежные места.
4️⃣ Делай ревью кода — баги легче ловить на стадии пулл-реквеста.

Итог

Жизненный цикл бага — это не теория из книжки. Это рутина любого проекта: от маленького стартапа до энтерпрайза. Если у тебя багов нет — значит, у тебя никто ничего не трогает. Так что баги — это норма. Главное — чтобы они не жили дольше тебя.