Гайдар Магдануров : Philosophy

Время разбрасывать баги и время собирать баги

gaidar — Sun, 05 Jul 2009 22:17:00 GMT

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

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

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

Сегодня мне довелось всласть покопаться в старом коде, работающей в боевом режиме уже почти шесть лет, и поэтому я решил поделиться моей практикой исправления багов.

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

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

К чему такие сложности, скажете вы, и окажетесь правы в большинстве случаев. Действительно, порой трата времени на столь тщательное исправление багов оказывается экономически неэффективной, однако, взгляните на эту проблему с другой стороны:

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

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

Успехов в кодинге!

Гайдар

Spb MobileShell 2- iPhone подвинься

gaidar — Fri, 07 Mar 2008 16:49:00 GMT

Истерия вокруг iPhone во многом была связана с уникальным интерфейсом, позволяющим легко управлять телефоном с помощью нескольких движений стилусом. Теперь похожие возможности есть у любого владельца телефона с Windows Mobile, установившего себе Sbp MobileShell 2!

Wi-Fi и Билайн – две вещи несовместные…

gaidar — Mon, 09 Jul 2007 13:32:00 GMT

Давно я что-то не писал в свой блог, пожалуй пора снова начать. Ну и конечно, чтобы веселее было, нужно кого-нибудь обругать хорошенько. Сейчас мне под горячую руку попался Билайн, его и поругаю J.

Нарисуем картинку. Сижу я в аэропорту Пулково и ожидаю, когда же объявят регистрацию на мой рейс, ну и, чтобы не терять зря время, решил поработать и отправить коллегам пару писем. Но каково же было мое удивление, после того как сайт Билайн, открывающийся при попытке открыть какой-нибудь URL в сети, с радостью приняв мою оплату и выдав мне логин и пароль, отказался пускать меня в Интеренет. На любой введенный адрес он отправлял меня на весьма информативную страничку, приведенную ниже:

Дабы уведомить уважаемых граждан из Билайн о таком вот нехорошем явлении, я написал им feedback через форму на сайте (19 уже поздно, чтобы звонить в поддержку, мы же знаем J) и меня снова ждало удивление – форма отправки feedback ругалась на мое имя. Посмотрев на код странички я обнаружил, что все дело в том, что для проверки используется регулярное выражение, не принимающее пробелов (только буквы):

    var rex = new RegExp("^[а-я,a-z]{1,}$", "i");
    if(!rex.test(cname.value))
    {
     alert('Имя должно состоять только из букв и содержать более одного символа!');
     return false;
    }

И эта история навела меня на мысль, почему в нашей стране, где просто огромнейшее количество ИТ специалистов и талантливых программистов, практически все публичные сервисы делают люди, «набранные по объявлению из ПТУ» ((с) коллега Крючков)?

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

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

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

В связи с этим я призываю быть требовательнее, сообщать о проблемах разработчикам, а если они будут игнорировать наши требования, пользоваться услугами тех, кто на эти требования будет реагировать. Даешь качественный ИТ сервис в массы! J