Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

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


RGB

1 247 просмотров

 Поделиться

63bbec018db9f2e53c98c53f34314871.png

 

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

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

 

Шаг 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 минут своего времени на описание бага и получил бы стократ больше – свежий приток новых клиентов, уважительное отношение к себе со стороны автора и хорошую репутацию, которую не купишь рекламными постами. Не спешите писать в комментах «если бы да кабы», сперва прочтите следующий пункт.

 

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

 

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

 

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

 

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

 

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

 

 

  • +1 11
 Поделиться

9 комментариев


Рекомендованные комментарии

23 минуты назад, nikifalex сказал:

Я в молодости очень много писал авторам модулей насчет их багов, но практически ниразу никто не прислушался и не исправил.

 

Тогда я понял, что нужно действовать иначе - надо клиенту сообщать о баге, и пусть клиент сам решает:

- писать автору модуля чтобы исправил бесплатно.

- просить исправить меня платно.

 

Что интересно, 90% приходили ко мне со словами "да автор не отвечает/не исправляет/только обещает". И сполна оплачивали исправление.

Адекватные авторы мне просто дают исходники закодированных модулей, чтобы я сам исправлял-дорабатывал.

С неадекватными разбираются сами заказчики, это не мои проблемы.

 

 

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

 Так что этику ту вертели многие разрабы, но ряды чистятся

  • +1 1
Ссылка на комментарий
39 минут назад, buslikdrev сказал:

Пусть покупатели следят за обновлениями.

 

Чего за ними следить если фиксов нет и многие владельцы вообще не в курсе из чего там собрали их франкенштейна

  • +1 1
Ссылка на комментарий
47 минут назад, nikifalex сказал:

Я в молодости очень много писал авторам модулей насчет их багов, но практически ниразу никто не прислушался и не исправил.

 

Тогда я понял, что нужно действовать иначе - надо клиенту сообщать о баге, и пусть клиент сам решает:

- писать автору модуля чтобы исправил бесплатно.

- просить исправить меня платно.

 

Что интересно, 90% приходили ко мне со словами "да автор не отвечает/не исправляет/только обещает". И сполна оплачивали исправление.

Адекватные авторы мне просто дают исходники закодированных модулей, чтобы я сам исправлял-дорабатывал.

С неадекватными разбираются сами заказчики, это не мои проблемы.

 

Спасибо за конструктивное дополнение, надо добавить вариант информирования одних лишь клиентов, но тут есть один момент. Даже если практически никто не прислушивался к вам, это же не значит, что всех надо мести под одну гребенку? Я не привожу себя в пример типа "смотрите какой я классный", можете относиться ко мне как угодно, но опять же – пример из личного опыта. В хорошо нам известной сборке .про версии 2.3.0.2.3 был небольшой баг, связанный с отображением вспл. окон при включенном ЧПУ (как на странице возврата товара), при нажатии сюда:

Спойлер

6fbb33cb490050dfc088a0aa15ba4a0d.png

получалась такая беда:

Спойлер

5aee229ce5309727d640498916bf047a.png

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

 

Или вот еще пример, за которым далеко ходить не надо - отметившийся выше @buslikdrev, будучи вполне грамотным специалистом, как-то пару лет назад решил сделать своеобразное «доброе» дело и наказать неосмотрительного новичка-разработчика шаблона @Medialine, выложив прямые ссылки на файлы его шаблона, доступ к которым тот забыл закрыть:

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

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

Ссылка на комментарий
В 21.09.2021 в 18:48, RGB сказал:

Можно было раструбить об этом небольшом баге среди всех моих клиентов-пользователей сборки?

Баг не сборки, а OpenCart - в common.js тег был не дописан:

https://github.com/opencart/opencart/commit/13a73a6700999ddeb30e451d235b4d14f5f6aa89#diff-141b748b41cde2b3fdc2fcc8d624a578a3a3d83968ad84dbb9674df238f18644

 

В 21.09.2021 в 18:48, RGB сказал:

С одной стороны - эти файлы сами по себе особой ценности, конечно, не представляли, поскольку без модуля управления шаблоном были в целом бесполезны,

Я это успел набросать в тот день, потом забил на шаблон, хотя доделать можно.

 

Это мой код 100% (администрация пишите в лс):

 

 

В итоге сохранение тех файлов облегчает копирование шаблона в разы.

Ссылка на комментарий
12 минут назад, buslikdrev сказал:

Я это успел набросать в тот день, потом забил на шаблон, хотя доделать можно.

Просто любопытно, с какой целью вы это сделали? Он вам нагрубил или как-то еще дорогу перешел? Или просто «потому что могу»? 

Ссылка на комментарий
13 минут назад, RGB сказал:

Или просто «потому что могу»?

И шаблон понравился и помимо этого там была проблема серьёзней - БД скачивалась.

 

В итоге выбрал этот шаблон:

 

Ссылка на комментарий

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

  • +1 2
Ссылка на комментарий
В 22.09.2021 в 22:42, SooR сказал:

сейчас хочу чтобы мне о них писали

Так назло не пишут же! :) Молчат, страдают, ждут звездного часа для своего перформанса (чтоб ррраз - и навалить кучу прилюдно, как в случае выше), за спиной критикуют (пока не словишь, опять же, как в случае выше), прикрываются неудачным "опытом коллег", список можно продолжать бесконечно..

Ссылка на комментарий

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Сейчас на странице   0 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.