Время разбрасывать баги и время собирать баги
Старый, пропахший давно забытыми багами чужой код. Кажется, что вот эти несколько классов покрылись плесенью, а эти алгоритмы от старости перестали корректно выполняться. И вот вам, одев самые толстые перчатки и болотные сапоги, нужно погрузиться в этот код, чтобы придавить парочку поднадоевших жучков. Риск велик, вам одному и без страховки придется погрузиться в эту дурно пахнущую пучину и возможно, вам не удастся выбраться оттуда никогда…
Думаю, что я разбудил ваше воображение, поскольку уверен, что разбираясь в чужом коде, доставшемся на поддержку, вы чувствуете что-то похожее. Но так все же, как вы решаете эту нелегкую задачу?
Почему я спрашиваю, потому что все чаще и чаще встречаю ситуацию, когда для исправления бага быстро втыкается костыль, который работает только в тех ситуациях, которые часто встречаются и про этот костыль тут же забывают, не говоря уже о том, чтобы хорошо его задокументировать.
Сегодня мне довелось всласть покопаться в старом коде, работающей в боевом режиме уже почти шесть лет, и поэтому я решил поделиться моей практикой исправления багов.
Прежде всего, нужно решить насколько этот проект критичен, будет ли он в дальнейшем поддерживаться или отомрет – это необходимо для психологического настроя. Зная, что проект важен, а исправление старого и такого родного пользователям бага не прихоть начальника, вам будет гораздо приятнее идти по описанной ниже дорожке.
- Перед тем как приступать к исправлению бага, создайте базовый unit-тест, который позволит удостовериться в качестве выполненного исправления. Очень важно учесть все сценарии использования кода, в который будут внесены изменения. Да, это больно, я согласен, но это нужно сделать, чтобы потом не было больнее. Представьте себе, что вы сейчас ставите пломбу, чтобы потом не вырывать весь зуб целиком.
- После того как баг будет исправлен, а тесты будут успешно выполняться, не спешите закрыть проект и уходить пить пиво, порой пиво может подождать – дайте ему получше охладиться в холодильнике. Посмотрите на причину возникновения бага и поищите аналогичные фрагменты кода, где может встретиться подобный баг. Сейчас, пока в вашей голове свеж опыт исправления одного бага, самое время справиться с аналогичными. Не забывая о
лечении зубов написании unit-тестов.
- По ходу исправления бага и его аналогов, подумайте, а не таится ли за только что исправленным багом еще один, а то и целый выводок. Вполне возможно, что этот баг маскировал другие – неплохой момент, чтобы проверить точки входа и выхода и поискать возможные баги, скрытые только что исправленным.
- Ну и наконец, нужно сделать вывод о том, что стало причиной появления этого бага, как не допустить таких в собственном коде и, главное, пометить себе, что такое встречается в жизни.
К чему такие сложности, скажете вы, и окажетесь правы в большинстве случаев. Действительно, порой трата времени на столь тщательное исправление багов оказывается экономически неэффективной, однако, взгляните на эту проблему с другой стороны:
- недобитый баг восстанет и плюнет в вас ядом в самый неподходящий момент, когда на носу сдача нового функционала заказчику, новый проект, переезд и пополнение семейства?
- приобретенный в процессе исправления багов опыт окажется очень полезен в дальнейшей работе
- навыки чтения чужого кода очень полезны разработчику, учитывая, что редко когда есть возможность переписывать все заново
В следующий раз, исправляя баг, позвольте ему вас чему-нибудь научить. А потом перепродайте это знание кому-нибудь подороже.
Успехов в кодинге!
Гайдар
