Сегодня хотелось бы поговорить с вами о такой теме как Легаси.
Давайте дадим определение, что такое легаси.
Легаси - это тот код, который писали до нас и который пришел нам от других.
Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.
Почти любой проект со временем превращается в легаси, если его не обновлять.
На своем опыте разработки я могу классифицировать легаси на три категории. Опять же я не претендую на абсолютную объективность. Это только моя классификация, на основе того, с чем лично я столкнулся.
1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.
2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке.
3) Плохое качество кода. Это ситуация, когда код писали не очень хорошо и люди, которые его писали уже давно недоступны. В итоге в их логике ничего не понятно. Но именно этот код то, на чем держится и работает приложение. В итоге на написание даже простых изменений уходит уйма времени. А уж про добавление к логике сложных фичей можно забыть или писать их не опираясь на эту логику. Лучшим решением является взять и написать это все заново. Посмотреть что и как работает. И написать свой вариант, предварительно убедиться, что ничего не сломалось. А затем отключить старый код.
Однако тут стоит упомянуть, что бывают случаи, когда старый код переписать нельзя. Или заказчик против, или есть какие-то обстоятельства. И тут остается только страдать и отлаживать по частям. У меня такое тоже было. Зато после такого кода, вам будет гораздо легче с нормальным и современным кодом.
Какие практики важны, если мы предполагаем, что любой код рано или поздно станет легаси.
1) Сложные участки кода лучше комментировать. Некоторые не любят комментарии в коде. Но когда есть сложный логический блок, то комментарии необходимы. Порой мы сами не помним, за что отвечает код, если писали его месяц назад. А представьте как тяжело другому разработчику в этом всем разобраться. А если прошел не один год?
2) Стараться оставлять себе ходы для отступления. Я имею ввиду, чтобы код можно было поправить, дополнить, а он не выглядел так, будто дерни какую-то функцию и все развалится. Как это все раскидать больше зависит от ваших инструментов. Смотря на чем вы пишите. Потому, что на Vue и React реализация одной и той же штуки будет выглядеть абсолютно по-разному.
3) Помните - зачем вы это пишите? Не нужно писать то, что не пригодится или захламлять какими-то вещами, которые вам не понадобятся. Вы напишите, потом забудете. Потом придет кто-то другой и будет думать - а зачем это тут нужно?
4) Нейминг имеет значение. Можно конечно использовать бесконечные сокращения, жаргонизмы и прочее. Но поможет ли это понять, что за что отвечает? Конечно, если ваша стратегия запутать врагов, чтобы никто ничего не понял, то можно использовать скрытый шифр, известный только вам. Тогда ваши функции, методы и переменные точно никто не поймет. Да и вы сами станете незаменимым человеком, без которого все это просто не заработает.
Я давно слышал такую шутку - тут так плохо и запутанно все написано, чтобы те кто это писали были нужны всегда и их никогда бы не уволили. Ведь без них это работать не будет. Кто знает, может так оно и есть.
5) Заменяйте магические слова и числа на константы с понятным неймингом. Когда я только был джуном, я не понимал зачем все это нужно. Ну сравниваю я значение с числом 10, ну и что…Однако потом становится совершенно непонятно, причем тут именно 10 и прочее.
6) Напишите доку на свое приложение. Хотя бы простое. Чтобы было понятно какие блоки для чего нужны. За что они отвечают. Какие у вас кодстайлы. Кстати, кодстайлы
7) Кодстайл. Одна из ключевых вещей, когда вы ведете разработку не в одиночку. Да даже если и в одиночку. Это будет вас дисциплинировать. А с другой стороны вам же будет проще их дорабатывать и искать свой лучший код стайл. Да и холливары вам разводить будет не с кем.
8) Если у вас есть говнокод, который вы не успели исправить, нужно тоже оставлять себе заметку об этом. Кроме вас об этом никто не вспомнит. А исправлять вам это все равно потом придется. Костыли сами себя не починят. Или починят, но уже без вас.
9)Если какой-то код можно написать просто, то пишите просто. Я вот никогда не понимал, зачем городить какие-то велосипеды и сложные схемы, если все можно сделать максимально просто и это будет работать. Не нужно усложнять. Чем проще - тем лучше. Вот один из моих основных принципов. Простой код и рефакторить легче и переписывать и разбираться.
Если вам пришлось работать с легаси, это не значит, что это проклятие. Возможно вам даже повезло в чем-то разобраться.
Важно уметь отличать поддерживаемое легаси от неподдерживаемого, которое дешевле переписать.
Работа с легаси кодом это особый навык.
Как когда-нибудь мы все с вами станем старыми, так и любой наш код когда-то превратиться в легаси. Жизнь она идет одинаково и для людей и для кода.
Комментарии (4)
Habruser2025
27.08.2025 06:19В рассуазах о математике физике с античных времен события оптсываются с хронологией развития. К коду нужен похожий подход. И не бэк, фронтэнд, а мат.база и прикладные решения
Feedman
А если это говно код на старых технологиях? В середине 00-х я игрался с веб-сервисами со всякими a = b + c, а потом внезапно нарисовался клиент, которому нужен был доступ к бд через плохие линии. С каждым новым клиентом была мысль "ну этот точно последний, потому что никому не нужно". Вот так и протянул 15 лет.
Yarisson Автор
Ничего себе как бывает