次の方法で共有

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

  • [アーティクル]

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

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

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

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

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

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

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

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

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

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

Гайдар

Comments

  • Anonymous
    July 08, 2009
    Все хорошо, только ссылки на Майкла Физерса или Кайла Бейли не хватало для пытливых читателей.

  • Anonymous
    July 12, 2009
    Тут от вашего имени пришло письмо "Microsoft открывает исходный код!", датированное "Том 13, выпуск 13, 2 июля 2009 г". Не могли бы вы указать где можно узнать для каких именно билдов .Net Framework доступен исходный код. Сама новость, вобщем-то, не нова, помню были времена когда действительно были доступны исходники для версии 3.5, потом я установил 3.5 Sp1 и на этом шара закончилась :(. Вроде все сделал как указанно вот тут: http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx - не прокатило: пишет, что исходный код не доступен. Не понятно, то ли я сделал что-то не так, то ли он действительно не доступен для версии установленной у меня. System.dll: 2.0.50727.3053 (netfxsp.050727-3000) WindowsBase.dll: 3.0.6920.1427 PresentationCore.dll: 3.0.6920.1427 PresentationFramework.dll: 3.0.6920.1427 System.Windows.Presentation.dll: 3.5.30729.1

  • Anonymous
    July 12, 2009
    Посмотреть список сборок, код которых опубликован, можно здесь: http://blogs.msdn.com/rscc/default.aspx

  • Anonymous
    July 13, 2009
    Зашел на указанный вами сайт, потом нечего не меняя в настройках снова попробовал загрузить исходник для первого попавшегося класса, и, заработало! Пасибо.

  • Anonymous
    July 14, 2009
    Чудо не случилось. Как такое может быть: грузятся исходники FrameworkElement.cs, UIElement.cs и многих других, а вот для класса GridViewRowPresenter ответило, что нет исходника, хотя он из того-же PresentationFramework.dll?

  • Anonymous
    July 15, 2009
    Описание собственных терзаний по доработке проектов 4-летней давности?

  • Anonymous
    July 15, 2009
    У меня много проектов, с коротыми время от времени приходится разбираться. Свои собственные в том числе, конечно, но они, пожалуй, доставляют меньше всего хлопот.