Category: мода

Category was added automatically. Read all entries about "мода".

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

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

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

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

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

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