Яков Сироткин (yakov_sirotkin) wrote,
Яков Сироткин
yakov_sirotkin

Рефакторинг: багофикс

Иногда случается, что ошибок в программе так много, что дешевле и проще написать всё заново, а не исправлять существующее. Возможно, когда-то это был вполне реальный сценарий. Однако, в наше время было бы не самым лучшим решением предложить менеджеру списать все уже сделанные инвестиции и начать разработку по новой. Тем более, что современные системы гораздо интенсивнее интегрируются друг с другом, поэтому переписывание проекта с нуля потребует очень много времени, чтобы поддержать все интерфейсы, а в уже запущенные проекты часто нужно вносить срочные изменения.

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

Очень часто баг можно исправить без включения мозга — например, добавить ещё несколько if где попало. Так создаются рабочие места для специалистов по рефакторингу. Правильная стратегия состоит в том, что сначала нужно научиться воспроизводить баг. Если сходу не получится, то нужно посмотреть код и понять, откуда он мог взяться, в этом хорошо помогает качественный лог. После этого нужно разобраться в деталях, как именно появляется баг: иногда проблемы наблюдаются при отображении, а ошибка происходит при загрузке данных или даже при их записи в базу. Когда уже понятно, в каком месте нужно исправить, необходимо посмотреть, что происходит вокруг этого кусочка, возможно, теперь весь метод целиком можно существенно упростить: убрать ненужные входные параметры, воспользоваться стандартной функцией. Разумеется, имеет смысл проверить, не раскопирован ли ошибочный фрагмент по всему проекту, и, возможно, добавить метод, который заменит все такие копии.

Качественное исправление багов безусловно идёт на пользу проекту, делает его более понятным и способствует дальнейшему развитию. Увы, часто разработчики предпочитают сделать очень быстро, лишь бы начальство скорее отстало. Это неправильно: всегда можно уйти с работы попозже или прийти пораньше, но сделать действительно хорошо. По большому счёту, пути два: либо вы добросовестно исправляете баги с самого начала, проект постепенно стабилизируется и вы спокойно спите по ночам, либо вы всё делаете тяп-ляп, проблем становиться всё больше, вы начинаете работать по выходным и всё равно не справляетесь.
Tags: refactoring
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 46 comments