Искоренение legacy

Поздравляем, вы успешно сделали тестовое задание и прошли собеседование в IT-компанию. Получили хороший такой оффер и вас определили в новую команду и только приступили к работе над проектом, как оказалось, что он состоит из «костылей», а часть старого кода лучше не трогать, если и так всё работает. Знакомо или нет? Читай.

Legacy code — это код устаревший код, который достался в наследство от предыдущих разработчиков. С каждым годом его всё труднее и мучительнее поддерживать, особенно, если в наследство не досталось внятной документации. В нём нереально разобраться (или реально, но очень долго).

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

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

Легаси — это не какое-то преступление, а часть жизни любой живой IT-компании. Рано или поздно на любом проекте возникает легаси. И чем крупнее проект, тем больше его будет.

Причин появления легаси может быть несколько:

Для бизнеса, это:

А ещё приходится тратить ресурсы на «поддержку старого кода»?

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

Не всякая крутая идея реализуема, ибо всё в нашем мире немного сложнее.

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

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

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

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

Переписать легаси — долго, дорого и рискованно.

Разделить всю старую кодовую базу на маленькие кусочки и обновлять по частям. Относительно безопасный способ с точки зрения целостности системы и влияния на процессы.

У нас выйдет либо модульный монолит, либо микросервисная архитектура.

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

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

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

Это достаточно рискованно в условиях постоянно меняющегося рынка. Может так получиться, что через год-два мир поменяется в очередной раз, а мы получим на выходе непонятно что.

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

Выделять время в инженерные дни на мониторинг индустрии. Если какие-то технологии или ПО устаревают, надо планировать переход на новые технологии.

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

Покрывать систему тестами и следить за актуальностью документации. Приостанавливать разработку и проводить рефакторинг кода, когда «костылей» (временных заглушек, которые чаще всего остаются постоянными) становится слишком много. Следить за чистотой кода (как минимум настроить линтеры, проводить ревью). Важен баланс, так как постоянный рефакторинг в борьбе за «скорость разработки» отнимает время от разработки.

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

От легаси никуда не денешься. Оно всё равно будет появляться и с ним предстоит сосуществовать и модернизировать. Это стоит воспринимать как часть работы. Или как новый опыт, если вы ещё на старте карьеры.