Как с этим жить?
Продуктов без багов не бывает, бывает лишь различная степень толерантности к ним. Последняя зависит от сферы, в которой функционирует ваше ПО. Например, если вы пишете код для бортового компьютера космического корабля, логично предположить, что толерантность к багам будет нулевой. Тем не менее, когда на гитхабе опубликовали исходный код программы для бортового управляющего компьютера «Аполлона-11», пользователи сервиса нашли места, которые можно было поправить. Пусть это были баги уровня опечатки (и расширения для спасения Мэтта Деймона, но их мы в расчет не берем), но они присутствовали.

Наличие незакрытых тикетов в багтрекере – это не свидетельство некомпетентности и не трагедия. Да, здесь автор немного драматизирует, прочитав на stackexchage трэд о том, как стать zero-bug programmer (ответ: не писать код или найти себе плохих тестировщиков).

Более того, если у вас много неисправленных багов, вы знаете о них и приняли осознанное решение не вносить правку – это здорово! Вы знаете ваш продукт и готовы ко всему!


Судьба бага
Этика и профессиональная гордость подсказывают нам, что необходимо фиксить все баги, которые мы можем найти, но реальность оказывается сложнее. Есть два типа багов:
• баги, которые нельзя не поправить;
• все остальные.

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

В эссе основателя Source Gear Эрика Синка My life as a Сode Economist автор предлагает задавать себе по поводу каждого бага четыре вопроса:

1. Степень критичности: когда этот баг повторяется, каков его негативный эффект и насколько он критичен для системы?
2. Частота: как часто он повторяется?
3. Цена: сколько усилий и ресурсов нам потребуется, чтобы поправить этот баг (пока мы правим баги, мы не делаем что-то новое)?
4. Риск: чем мы рискуем, когда правим этот баг (любое изменение кода – это риск)?

Иногда разработчик отвечает на эти вопросы в собственной голове за считанные секунды. Бывает, что приходится собирать консилиум и расставлять приоритеты в течение нескольких часов. Но правильное решение есть всегда. Главное – помнить, что ваши баги либо приносят вам деньги (хотя бы потому, что пользователь готов с ними мириться), либо заставляют вас их терять. Впрочем, мы желаем вам поменьше жучков обоих типов!