Какие баги никогда не будут поправлены, и как с этим жить

Все продукты получаются неидеальными. Да-да! С багами! Некоторые из них никогда не будут поправлены. Произнесите это слово по слогам, чтобы почувствовать всю обреченность и окончательность этого вердикта: ни-ког-да!

Тип 1. Баги, связанные с устаревшими устройствами и программами

Если вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет.

Здесь стоит сделать оговорку: все же не стоит отсекать идею пофиксить подобный баг сразу. Все нужно соотносить с полезностью для пользователей и вашими затратами. Например, если вы потратите на фикс 10 минут, а «спасибо» вам при этом скажут десятки тысяч человек, нужно браться за работу. А вот тратить 20 часов для одного пользователя бесплатной версии, который отписался под одним из ваших постов на Хабре годичной давности, – это непродуктивное решение.

Тип 2. Баги в сторонних компонентах

У программиста может не быть компетенций для исправления ошибки, если в его решении используется сторонний компонент. Зачастую это классическая проблема «черного ящика»: три дырки на входе и три дырки на выходе, код закрыт, лицензия проприетарная. Но даже открытый исходный код не гарантирует того, что проблему в принципе можно решить. Например, разработчики ПО на основе OpenOffice не правят баги в OpenOffice, потому что знают, что просто не смогут потом его собрать.

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

Тип 2 и 3/4 . Баги, связанные с технологией

Представим ситуацию: создавая веб-приложение, вы имеете дело с ограничениями, которые накладывает браузер (например, с неспособностью распознать текущую раскладку клавиатуры).

Вот реальная ситуация: в текстовом процессоре Microsoft Word язык проверки орфографии меняется в зависимости от того, в какой раскладке вы набираете текст, в то время как в онлайн-редакторе вам придется задать язык проверки орфографии вручную. Таким образом, пытаясь вести себя как пользователь Microsoft Word (что в общем-то логично), пользователь онлайн-редактора испытает неудобства, а вы не можете ему помочь, так как находитесь в естественных границах технологии.

Но, как и в случае с багами в компонентах, здесь есть оптимистичный сценарий. Проблема, которая не может быть решена в рамках конкретного продукта, может решиться сама по себе по мере развития технологии. Да, сейчас браузеры не интегрированы с системой достаточно тесно и поэтому не имеют доступа ко многим системным ресурсам, но кто возьмет на себя смелость сказать, что так будет всегда?

Тип 3. Баги, которые никогда не воспроизведутся у пользователей

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

В эту же категорию попадают латентные баги, которые юзер никогда не увидит, потому что выцепить их можно только в коде.

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

Тип 4. Баги, которые сложно повторить

Как правило, это ошибка, которая повторяется при условии, что ваши GPS-координаты сообщают, что вы в Зимбабве. И вы стоите лицом на восток. По колено в воде. В новолуние. И ровно в полночь вам приходит push-уведомление.

Тип 5. Баги, которые приносят деньги

История из жизни: в одной компании, занимавшейся мультимедийным софтом, делали бесплатную программу. Во время ее установки пользователя вежливо спрашивали, не желает ли он установить еще и расширение для браузера. При этом чекбокс оставался серым, а галочка «Установить расширение для браузера» стояла по умолчанию, так что создавалась иллюзия неактивности этого элемента интерфейса. Хотя, знаете что? На самом деле ее можно было убрать. И как вы уже могли догадаться, монетизация бесплатного приложения была организована именно с помощью этого расширения. Серый чекбокс – очевидный баг, с обнаружения которого прошло уже много лет, но его до сих пор не поправили.

Тип 6. Баги, которые ни на что не влияют

Обычно это что-то незначительное: например, пустая div’ка в html-коде. Это несомненный баг, но поскольку он сидит себе и не высовывается, то и править его никто не будет.

Тип 7. Баги, за которые никто не отвечает

Если в предыдущих пунктах речь шла о багах, которые невозможно или даже не нужно править, то здесь мы поговорим о типе багов, являющихся симптомом опасной болезни. Это баги, появившиеся в процессе создания той части продукта, «на которую всем плевать» (потому что никто толком за нее не отвечает).

Абстрактный сценарий такой: несколько отделов создают общую фичу. Сначала дизайнеры нарисовали кнопку и забыли. Потом программист из отдела 1 в силу своей загруженности подготовил компонент, забыв пробросить туда кое-какие методы. Программист из отдела 2 взял готовый компонент и вставил его в продукт без исправлений. Работает? Скорее всего, работает, но при этом может, например, выглядеть уродливо. Ну а поскольку для всех героев это была всего лишь побочная задача среди сотен других, то все так и остается.

Баги, за которые никто не отвечает, могут быть довольно критичными. При этом их никто не будет фиксить до тех пор, пока пользователи молчат. И это тревожный звоночек… а может, даже целый колокол! Звонит он не только и столько по заброшенной части продукта – он звонит по организационным процессам в компании.

Как с этим жить?

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

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

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

Судьба бага

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

баги, которые нельзя не поправить;
все остальные.

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

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

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

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