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

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

Что такое легаси-код

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

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

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

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

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

К слову, легаси — это не только код. Это и устаревшие системы или архитектурные решения, которые больше не соответствуют современным требованиям или стандартам, а также библиотеки или фреймворки, которые больше не поддерживаются.

Откуда берётся легаси

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

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

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

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

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

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

Чем грозит легаси в работающем продукте

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

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

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

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

Как работать с легаси-кодом

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

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

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

Правило 80%

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

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

Постепенная переработка

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

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

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

Рекомендации по работе с легаси от Майкла Физерса

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

• Тестирование. Прежде чем вносить изменения в легаси-код, напишите тесты, которые позволят проверить его работоспособность после изменений.
• Изоляция изменений. Вносите изменения в код так, чтобы они были изолированы от системы в целом.
• Декомпозиция и обновление кода. Делите большие монолитные классы и методы на более мелкие, лёгкие в управлении части.
• Поэтапный рефакторинг. Проводите рефакторинг небольшими итерациями, чтобы контролировать риски и проверять работоспособность системы на каждом шаге.
• Работа с зависимостями. Снижайте количество зависимостей между компонентами кода, чтобы упростить его поддержку.
• Разделение ответственности. Принцип единственной ответственности (Single Responsibility Principle) предполагает, что одна часть системы отвечает за одну функцию. Это помогает уменьшить связанность компонентов и делает систему более гибкой.
• Документирование изменений. Фиксируйте все изменения в коде, чтобы другие разработчики понимали, что и почему вы изменили. Так ваша обновлённая база не превратится в легаси.
• Обратное проектирование. Понимание структуры и логики старого кода через обратное проектирование (aka ревёрс-инжиниринг) помогает избежать непредсказуемых последствий при внесении изменений.
• Код-ревью. Внедрите практики код-ревью — это помогает выявлять проблемы на ранних стадиях и поставлять код лучшего качества.
• Автоматизация рефакторинга. Используйте инструменты автоматизации рефакторинга, чтобы ускорить процесс и снизить вероятность ошибок.
• Обучение команды. Обучение команды новым подходам и технологиям поможет улучшить качество кода и снизить вероятность появления легаси в будущем.

Рекомендации от компании arcsinus

• К перечисленным практикам и инструментам мы бы добавили статические и динамические анализаторы кода.

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

• Полезно взять в пользование какие-то code standards, созданные авторитетными инженерами — такие стандарты есть в Google и других крупных IT-компаниях. Для популярных стандартов существуют готовые линтеры, которые легко интегрируются в процесс разработки.
• На повышение общей культуры разработки хорошо работает практика использования Definition of Ready и Definition of Done.

‍

Этот материал опубликован на vc.ru