«Никто не знает, как это работает…» Что такое легаси и нужно ли всё переписывать

Легаси — страшный сон разработчика. Работа с ним может помочь получить грейд выше, а может серьёзно пошатнуть кукуху и даже стать поводом к увольнению по собственному. Сегодня поговорим, что за зверь это ваше легаси и нужно ли «всё переписывать».

Важно употреблять термины правильно: легаси — это не любой код, написанный не вами и до вашего прихода. И даже если новый разработчик с ходу не понял что-то в коде — это ещё не повод говорить о «легаси». Говорить о легаси можно, если вы столкнулись с этим 👇

1. Устаревшие технологии. Легаси-код часто написан на неакутальных версиях языков или с использованием устаревших фреймворков. И на деле важна не столько абстрактная «устарелость», сколько практические проблемы с поддержанием и развитием.

2. Недотестированность. Часто легаси-код недостаточно покрыт тестами. И тогда любые изменения грозят новыми багами.

3. Недодокументированность. Конечно, хороший код не нуждается в доках и вообще self-explanatory и self-documenting. И всё же документация нормальна и нужна на случай, если что-то неясно. Когда разобраться самостоятельно в функциональности и логике не удаётся, а документации нет — это легаси.

4. Нет того, кто участвовал в создании кода. Частный случай предыдущего сценария: есть проблемы с пониманием логики и задуманной функциональности + в компании уже нет того, кто может это пояснить.

Неужели всякий код со временем становится легаси? Это вообще нормально? Да, «зарастание» легаси — нормальная часть жизненного цикла ПО. Чем объёмнее проект и чем дольше он существует — тем больше вероятность появления легаси. Вот основные факторы, способствующие его появлению:

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

2. Давление сроков. Команды часто действуют в условиях жёстких дедлайнов и вынуждены идти на компромиссы по вопросам качества кода. Релизить приходится быстро, без тщательной проверки на чистоту и соответствие стандартам.

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

4. Отсутствие документации. Это и симптом, и причина. Новые члены команды затрудняются в понимании структуры и логики кода, а документации нет. Так он становится легаси.

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

1. Повышенные затраты на поддержку. Работа с «наследством» может требовать больше времени и ресурсов, а это, в свою очередь, увеличивает нагрузку на бюджет.

2. Увеличение технического долга. Легаси-код всегда ассоциирован с растущим техдолгом. Даже не принося урона в моменте, он представляет собой постоянно растущий риск отказа системы или её частей.

3. Риски безопасности. На практике устаревший код и библиотеки могут содержать ошибки и уязвимости — а это прямая угроза безопасности системы и пользователям. Приличный процент утечек ПД происходит как раз из-за устаревших технологий.

4. Сложности в развитии продукта. Легаси-код может ограничивать возможности добавления новых фич и усложнять интеграцию с современными инструментами.

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

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

Хорошая практика — «правило 80 %». Согласно ему, если 80 % кодовой базы может быть охарактеризовано как легаси и нуждается в рефакторинге, то стоит рассмотреть переписывание системы с нуля.

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

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

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

В 2004 году состоялась первая публикация книги Майкла К. Физерса «Эффективная работа с legacy-кодом» (Working Effectively with Legacy Code). И если отдельные примеры в книге несколько устарели, то общие рекомендации эксперта по-прежнему актуальны. Вот они.

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

На повышение общей культуры разработки хорошо работает практика использования Definition of Ready и Definition of Done.