этика Профессиональная этика: нашел баг у коллеги, что делать?

Давно были наброски для этого поста, а тут так кстати подвернулась ситуация, на примере которой можно рассмотреть данный вопрос .

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

Шаг 1. Повторение – мать учения

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

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

Шаг 2. Насколько все серьезно?

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

• Если мы говорим о дополнениях для OpenCart, то стоимость таких дополнений и средние бюджеты в проектах далеки от высоких, поэтому требовать "Pixel perfect" от какого-нибудь шаблона за 20$ – бесполезно
• Не все разработчики вообще обновляют дополнения, поэтому и ошибки в них могут существовать годами, а то и весь срок жизни дополнения
• Те, кто регулярно выпускают обновления, не делают это каждый день из соображений как собственного удобства (разошлите экстренное обновление тысяче пользователей и через день непременно найдете новый баг, поверьте), так и удобства пользователей (все любят регулярные обновления, но никто не любит тратить время на их установку)
• Обычно в обновление входит исправление сразу множества ошибок, поэтому исправления пары незначительных багов обычно ставится в очередь для подготовки более крупного обновления

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

Шаг 3. Уведомление или неуведомление автора

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

1. Промолчать
2. Уведомить, но не автора
3. Уведомить автора

Разберем каждый из вариантов, его плюсы и минусы.

Шаг 3.1 Молчание

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

Шаг 3.2 По секрету всему свету

Бывает и так, что обнаруживший баг специально решает скрыть это от автора, но рассказать это другим лицам (конкурентам, читателям, администрации, кому-угодно еще). Мотивация таких персонажей бывает самой разной – от банальной зависти и конкурентной борьбы до простого и старого, как мир, желания исподтишка нагадить ближнему. Справедливости ради стоит заметить, что есть некоторые авторы, которые категорически отрицают любую критику и воспринимают ее в штыки, поэтому бывает и так, что вы многократно следовали шагу 3.3, но это не дало результатов, поскольку к автору просто невозможно достучаться из-за его собственного упрямства и у нашедшего баг остается только два варианта – молчать или подключать третьих лиц.
Плюсы: к багу привлечено внимание, вы ощущаете себя Д'Артаньяном
Минусы: баг все равно может остаться неисправленным, а отношения с автором с большой долей вероятности будут испорчены

Шаг 3.3 Профессиональная этика

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

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

Плюсы: баг исправлен, автор (как правило) признателен

Минусы: автор (иногда) может затаить злобу и не прислушаться к советам, а вы уже не сможете посадить подготовленного автора в лужу

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

Эта информация про артикулы и H1 не являлась новой для меня и я ее видел еще несколько лет назад в отчете довольно известной компании WebPromo, специалисты которой тогда готовили 100-страничный SEO-аудит сайта знакомых и в одном из пунктов прямо советовали «уникализировать заголовок H1 посредством добавления артикула». В то время я не придал должного внимания этой технике (зря, конечно), отложив реализацию на будущее, а потом благополучено забыл об этом, за что мне стыдно Но речь не об этом.

Что можно было сделать в такой ситуации?

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

Хороший пример
А вот другой пример из личного опыта с человеком, в особых симпатиях к которому меня точно сейчас не заподозришь  Опять же, несколько лет назад, когда мы еще нормально общались и мой оппонент производил в целом адекватное впечатление, у него был в работе проект с моим шаблоном, в котором была обнаружена неприятная проблема – в блоке быстрого поиска я не догадался поставить небольшой таймер для задержки поискового запроса. Поэтому при быстром наборе этого самого запроса каждое нажатие клавиши вызывало отправку запроса на сервер и получение ответа, из-за чего окно поиска мерцало, а сервер вместо того, чтобы с небольшой задержкой сразу искать один товар "кресло" выполнял серию последовательных запросов, пытаясь найти товар "кр", "кре", "крес", "кресл", и т.д.

Что сделал мой оппонент в то время? Написал мне в личку «со всем уважением, вы тут не правы)» и объяснил суть проблемы. В итоге уже через день клиент, у которого эта проблема проявлялась, получил инструкцию по ее исправлению, в готовящемся обновлении шаблона тоже появилось это исправление, ну а мой оппонент получил не одну и не две рекомендации его услуг среди моих собственных клиентов.

Как мог поступить мой оппонент (и как, вероятно, поступил бы сейчас в такой ситуации)?

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

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