Соглашаться ли на рефакторинг? Алгоритм принятия решения | АйТи-капитан объясняет

Привет, я Михаил, проект IT капитан. Это видео про 

рефакторинг. Является продолжение моего видео про технический долг. Значит, рассмотрим следующую 

ситуацию. К нам приходят кто-то, разработчики либо менеджер проекта и просят выделить ресурсы на 

проведение рефакторинга. Что будем делать? Итак, погнали. Сначала определимость терминологией. 

Рефакторинг - это переработка изменения уже существующего кода. Там есть различные вариации. 

Просто чуть-чуть переписать, добавить убавить слав абстракция. Есть рефакторинг с целью оптимизации 

производительности и есть реинжениринг кода. Давайте так. Вот к нам пришли и предлагают 

что-то переписать. Неважно зачем, неважно почему, неважно как переписать. Это рефакторинг. Пойдём 

от простых ситуаций. Допустим, команда просит выделять на одного разработчика не 40 часов в 

недели на разработку новой функциональности, а 32. Таким образом, команды хочет, чтобы вот во 

время двухнедельного спринта 2 дня выделялось на поддержание гигиены кода, на выполнение задач 

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

решение: да, почему бы нет? Можно и согласиться. Рефакторинг как решение проблемы. Здесь на что 

обратим внимание? Во-первых, то есть к нам пришли вот с предложением переписать какой-то участок 

кода, какой-то раздел на проекте, какой-то модуль, компонент. Кто предложил, чья это инициатива? 

Jниor разработчик, midлle, senior или teamли. Какая аргументация? То есть что изменится, какую 

пользу принесёт рефакторинг? И нужно подумать о том, возможны ли здесь какие-то скрытые мотивы. 

Давайте на примерах. В видео про технический долг мы приходим к тому, что разработка зашла в тупик. 

Компонент приложения не устойчив к изменению, не поддаётся исправлению ошибок. Правим в одном 

месте, ломается в другом. И у нас идут жалобы служб поддержки, негативный отзывы в социальных 

сетях. У нас есть вариант не переписать этот компонент, чтобы исправить ошибки? Да нет, нет, 

уже пытались. Просто берём и переписываем. Вот короткое решение, да? Соглашаемся на рефакторинг. 

Далее возросло количество посетителей. на проекте или изменилась какая-то вот флоу использования тех 

или иных компонентов проекта. Взросла нагрузка, проект не справляется, тормозит. Ситуация ровно 

та же самая. Загружена служба поддержки, негатив в отзывах. Нам это не нужно, и мы хотим сделать 

так, чтобы проект работал хорошо и быстро. Поэтому, да, давайте по рефакторе с целью 

оптимизации производительности. Возможны ли скрытые мотивы? Да, возможно. Опять же, чья была 

инициатива? Возможна ситуация, когда над проектом работала группа профессионалов. Активная фаза 

разработки проекта прошла, основную часть команды перевели, например, на другой проект, а здесь 

на поддержку поставили начинающих разработчиков уровня Jниor. Может ли быть такая ситуация? что 

они просто не понимают, зачем нужны те или иные участки кода, те или иные слои абстракции, и им 

кажется, что можно было бы всё упростить. Да, такое возможно. И нет, мы не должны на 

это соглашаться. Бывают такие интересные, скрытые мотивы. Например, человек хочет уволиться, 

у разработчика чемоданное настроение, и он хочет сделать своё резюме более красивым, использовать 

какую-то современную актуальную технологию, применить её на своём текущем проекте, указать об 

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

просто не хочет работать с этим кодом. Ну, одно дело, что есть, например, просто 

особенность работы человеческого мозга, то, что сделана найм, мы сначала не понимаем, 

нужно пройти какому-то количеству времени. Но я сейчас про другую ситуацию. У нас есть старый 

проект, там куча Legacy лапшикода, 10 лет назад написанного разными командами. приходит хороший 

разработчик, который очень много усилий, времени вложил в своё развитие. Он читал книги, ходил на 

конференции, много практиковался, решал алгоритмы. И вот он приходит на ваш старый проект, смотрит 

на всё это и всё, у человека внутренний конфликт, он не хочет с этим кодом работать. Ему либо нужно 

уже опуститься как-то до уровня вот этого проекта, что ему делать совсем не хочется, либо проект 

дотягивает до своего уровня, и он прилагает: "Давайте перепишем". Вот бывает и такое. Так 

мы подошли к тому, что многие компании просто переписывают свои проекты полностью пишут с нуля 

либо полностью перерабатывают, тратят на это много месяцев, много ресурсов. Это делается в качестве 

инвестиции. Какие проблемы решит рефакторинг? Во-первых, увеличится скорость разработки внедрени 

новой функциональности. То есть мы сокращаем время. Time to market. Показатель у нас 

улучшается. Хорошо. У нас уменьшается количество багов. Второе, мы можем, во-первых, мы можем 

код написать уже, как бы исправив ряд ошибок, он пройдёт повторное тестирование. На этапе этом тоже 

выявится ряд ошибок и исправится. И переписанный код есть возможность покрыть юнит-тестами. 

Тоже уменьшаем количество ошибок на проекте. Далее, проблема найма. Вот как раз то, о чём мы 

сейчас говорили. На старый проект с Legси кодом мало кто хочет идти. Во-первых, нам сложнее найти 

человека, который на это согласится. Во-вторых, нам сложнее удержать человека на этом проекте. 

Вот он пришёл, увидел, что там ужаснулся и пошёл снова рези опубликовал. Как правило, приходится 

платить зарплату выше рынка для того, чтобы не было текучки. Ну и нам для принятия решения нужно 

взять во внимание перспективу проекта. Может быть, проект просто уже доживает своё, тогда, конечно, 

ничего менять не надо. Возможно, нам нужно просто брать менее квалифицированных разработчиков, 

которые просто занимались бы поддержкой проекта и всё, не более того. либо слабых разработчиков, для 

которых код на этом проекте казался бы наоборот клёвым, и они наоборот подтягивались бы. Такой 

вариант. Если перспектива у проекта хорошая и да, мы хотим его дальше развивать, внедрять новую 

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

большими нагрузками, да, можно подумать над тем, чтобы провести такой глобальный рефакторинг. Но 

здесь есть определённые риски. Давайте попробуем их минимизировать. взять проект и полностью 

его переписать - это довольно тяжёлая, долгая, объёмная задача, и в ней можно погрязнуть. 

Её всегда есть риск не закончить до конца, вплоть до того, что разработчики даже, которые 

инициировали этот рефакторинг, могут уже просто к тому времени сменить работу, и вы останетесь с 

недоделанной поделкой, переделкой вашего проекта. Поэтому лучше делать частями. Вот в этом месяце 

сделали рефакторинг этого компонента системы, в этом месяце другого. И да, можно сказать, что 

у нас монолит, там так не получится. Обычно, если сесть, хорошо подумать, проанализировать 

ситуацию, то можно придумать подход такой, где и в монолите получится рефакторить частями. 

Но если нас вообще нужно сменить стек технологии, мы можем подумать про микросервисы, какой-то 

пласт функциональности выделить в отдельный микросервис и просто даже поменять 

язык программирования и базу данных, пожалуйста. Далее. Рефакторинг делают 

профессионалы. Мы не даём делать рефакторинг Juniниор разработчиками. Очень серьёзно 

думаем над тем, дать ли рефакторинг медлам. Нет, нам нужны [музыка] профессионалы. Нужно, 

если мы в это вкладываемся, нужно сделать всё так, чтобы не пришлось потом сразу опять переделывать. 

Оцениваем эффект. А в зависимости от того, какую проблему мы решаем, мы выстраиваем какие-то 

метрики. Допустим, у нас, э, какой-то какая-то функциональность постоянно ломалась или 

добавление новой функциональности в какой-то компонент проекта занимало безумное количество 

времени. И вот мы переписали его и посмотрели, вообще стало лучше. Да, стало. Тогда берём в 

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

проведении или не проведении рефакторинга - это уравнение со множеством неизвестных. И это 

про деньги. Это вообще не про код, это про деньги. Нужно считать деньги, метрики, эффект от 

проведения рефакторинга и перспективы. Спасибо за просмотр. Подписывайтесь на мой канал. Будет ещё 

много интересного. Если вы хотите обсудить со мной ваш проект, я оставлю под видео свою контактную 

информацию. Вы можете мне написать. Всё, пока.