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

Какой рефакторинг нам нужен

Я давний адепт рефакторинга и много лет успешно его практикую (в своей интерпретации). Например, на предыдущей работе мы переписали десятки тысяч строк PL/SQL на Java. Начинали мы с того, релизы мы делали по 4 месяца и включали они в себя по 5-6 изменений, которые вносились через боль и страдание. Через 3 года мы легко могли сделать релиз за 3 месяца и включить в него 15-20 новых фич, потому что код стал понятным, а инциденты в боевой системе сошли на нет.

Однако, мой опыт ограничен узким кругом моих работодателей, а cartmendum   обобщил свои наблюдения и тут получается, что рефакторинг — это такое страшное проклятие. У меня есть теория, как получаются такие экспериментальные данные. Многие команды любят делать новые системы на основе модного стека технологий. Через несколько лет боли и страданий они внезапно осознают, что технологии у них уже совсем не модные и переходят к решительным действиям. Но так как корпоративная культура не изменилась, то на выходе снова получаем боль и страдание. Превышение срока разработки в 4 раза, да ещё без достижения нужного результата, говорит о том, что команда просто некомпетентна и не понимает, что делает и где находится.

Давайте вернёмся к рефакторингу с позитивной стороны. Система является проблемной, если разработчики не успевают вносить требуемые изменения за комфортное время, эту формулировку можно считать определением. Рефакторинг — это процесс улучшения системы, то есть после него внесение изменений должно проходить проще. Итак, если система проблемная, то разработчик вынужден задерживаться на работе, пусть у него уходит по 9 часов в день на выполнение поставленных перед ним задач. Если разработчик не любит плохой код, то он дополнительно тратит какое-то время на приведение его в порядок, допустим, это ещё 1 час в день. Итого, новый хороший разработчик в проблемном проекте работает по 10 часов в день. Но так как система становиться проще, изменения вносятся легче, то срочные задачи делаются всё быстрее, поэтому на рефакторинг остаётся больше времени и потребность в переработках отпадает. Заметим, что при таком подходе нет нужды спрашивать разрешения у начальства, можно просто хорошо работать и от этого появятся основания попросить прибавку к зарплате. Минус здесь в том, что чем больше времени остаётся на рефакторинг, тем быстрее система перестаёт быть проблемной и пропадает необходимость в хорошем программисте, я сам несколько раз проходил через это.

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

Очевидно, что для решения стратегических задач требуются специальные навыки, но систематическое применение рефакторинга на ранних стадиях позволит вам избежать получения проблемной системы. Понятно, что всегда есть соблазн сделать по-быстрому, а со всякими шероховатостями разобраться потом. Но идеи рефакторинга призывают поддерживать ясность кода с самого начала и таким образом снизить риски в будущем.
Tags: рефакторинг
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.
  • 17 comments