Lesson 97

После диалогов и диспутов: у меня появилось ощущение, что программисты не осознают, что они пишут баги с каждым коммитом. Сдается мне, они для себя как-то так решили: «Я пишу функционал, а баги появляются сами собой, даже если после моего коммита».

А прихожу к мысли, что это как-то и правильно даже, и ничего трогать и менять их мироощущение не надо.

Слово Канеру:

Не настаивай, чтоб каждый баг был исправлен. Выбери свою битву.



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

Страх неисследованных побочных эффектов заставляет опытных руководителей с осторожностью относиться к любому изменению в коде.

Другая замечательная причина в том, что заказчик может быть не готов платить за исправление. Это часто можно наблюдать в пользовательской, заказной и внутренней разработке. Со многими ошибками дешевле жить, чем исправлять их. Но часто удаленные заказчики идут на компромисс. Представьте себе работу над обновлением ПО, исправляющим критическую ошибку, удаляющую некоторые пользовательские данные. Программа с этим багом находится в реальном испрользовании. А теперь представьте, что релиз исправления откладывается из за исправления орфографических ошибок. В этом случае решение очевидно (не исправлять орфографию). Для менее очевидных решений проектная группа оценивает компромиссы для достижения баланса времени, стоимости, доступности фич, надежности.

Если ты не можешь придумать сценарий, когда эта ошибка станет важна или найти заинтересованных в ее исправлении лиц, мы предлагаем вам оставить эту ошибку и начать оспаривать что-нибудь другое.