Комментарии 16
Легаси код - это код, написанный человеком, который уже не работает в вашей компании
Сплошь и рядом такое. И что? Если код написан нормально (и внятно документирован), то он легко модифицируется. В противном случае его не сможет (без лютого костылинга) модифицировать даже тот, кто его писал.
Хороший код не требует документации, он и так понятен и структурирован.
Не всегда, увы.
Если код реализует какую-то сложную логику (множество условий, ветвлений) и использует нетривиальные алгоритмы для достижения предельной эффективности, то даже при хорошем структурировании сходу бывает сложно понять что именно он делает, не имея документации.
Такого в моей практике встречалось немало. И когда надо просто поменять что-то в логике, если код подробно не документирован (какую часть реализует данный конкретный блок и почему именно так), много времени уходит на анализ.
У нас написанный когда-то кем-то модуль может жить и работать годами пока вдруг не потребуется внести какие-то изменения. И вносить их будет совсем не тот, кто этот модуль писал. Да, у него будет FSD на модуль с указанием что именно нужно поменять по логике, но наличие в коде "привязок" к FSD очень сильно упрощает задачу нахождения конкретного куска где нужно что-то поменять и при этом не ухудшить эффективность всего модуля в целом.
Так ведь не бывает не legacy кода. Любой код становится legacy через несколько лет от его написания. И это нормально. Это не код legacy, это новый разработчик не осилил. Вот для него ярлык legacy - это типа оправдание.
Несколько лет это еще хорошо, часто код становится легаси уже на этапе влития в репозиторий
Ещё как бывает, хоть и понять это непросто. Legacy не просто называется этим словом. Оно буквально означает наследие, наследство. То, что осталось с каких-то времён, досталось от кого-то, кто был до. Т.е. оно очень тесно связано со врменем, его течением. Система, которую дописали сегодня утром, не может быть легаси. Достаточное время ещё не прошло. А теперь сложная часть: время это не ход стрелки часов, время - поток событий, пусть даже отдельных движений стрелки часов. Т.е. оно относительно, ведь поток событий везде разный, для всех разный. Для разных систем, написанных с использованием разных инструментов превращение в legacy происходит с разной скоростью. Взять фронт например. У js-ников каждый год новый, более прогрессивный фреймворк - проще, быстрее, удобнее, логичнее, лаконичнее. А у банковских систем на COBOL каждый год одно и тоже т.к. ни COBOL, ни процессы в бэкофисе банков могут не меняться десятилетиями. Соответственно "свеженькая" банковская система, которую для какого-нибудь швейцарского банка написали 7 лет назад вполне может быть на 100% современной и актуальной т.к. даже непонятно как её обновить.
А у банковских систем на COBOL каждый год одно и тоже т.к. ни COBOL, ни процессы в бэкофисе банков могут не меняться десятилетиями. Соответственно "свеженькая" банковская система, которую для какого-нибудь швейцарского банка написали 7 лет назад вполне может быть на 100% современной и актуальной т.к. даже непонятно как её обновить.
С одной стороны да - банки очень консервативны. Используют только надежные, выверенные временем решения (речь, конечно, о ядре банка - АБС, которая работает на центральных серверах). И если там что-то работает, никто не будет трогать просто ради того, чтобы перейти на новый модный стек - слишком там много всего, слишком сложная логика, слишком много взаимосвязей.
Второй момент - банки завязаны на законодательство и правила регулятора. Если что-то поменялось - необходимо менять логику и вносить изменения в код.
Третье. Банк развивается, развиваются технологии, появляются новые сервисы. Если разработчики мобильного приложения или интернет-банка придумали "новую креативную фичу", она должна поддерживаться на уровне АБС на центральных серверах. И при этом ее реализация не должна ухудшать все то, что уже работает.
Далее. Количество клиентов постоянно растет. И то, что три-пять лет назад всех устраивало по скорости, сейчас начинает работать неприлично долго, сильно грузить сервер и местами тормозить какие-то бизнес-процессы. И тут требуется оптимизация кода, реорганизация данных и т.п. Пример из личной практики - в модуле комплаенса есть операция построения стоп-листов по спискам РосФина (всякие злодеи-бармалеи). Когда-то давно она работала пару часов и все было хорошо. Потом и списки стали расти и количество клиентов выросло. Операция стала занимать 9 часов. Что уже никому не нравилось. Пришлось заняться оптимизацией. Уменьшили время до 4-х часов (приемлемо). Дальше все опять покатилось вниз - добавилось списков, выросло количество клиентов. 15 часов. Вообще никуда не годится. А тут еще РосФин подкинул - изменили формат списков. Под это дело переписали вообще все. Алгоритмы разбора списков, форматы БД их хранения, добавили витрины изменений, полностью переделали всю процедуру построения стоп-листов. Сейчас оно работает 10 (!!!!) минут. Но мама дорогая, сколько туда труда и времени вложено (тут к вопросу о TTM - можно сделать быстро и просто, как это изначально делалось, но потом будут проблемы с масштабированием, а можно делать долго и сложно, но и результат будет совсем иным).
Вывод - банк достаточно динамичная система где постоянно что-то внутри меняется. И да, есть модули которые работают годами, но при этом появляется что-то новое. Или что-то модифицируется потому что перестает удовлетворять новым требованиям. Все это требует постоянно внесения изменений, причем таких, которые не порушат уже работающее, не создадут избыточной нагрузки на сервер, не будут тормозить все остальное.
В целом, легаси кода тут очень много. Частично он "вымывается", частично живет очень долго.
Если человек не считает легаси кодом код своего прошлого проекта - то за всё это время с того проекта он ничему не научился и ничего нового не узнал, остался стоять на месте.
Для меня легаси - это код который отдебажен вдоль и поперек, он может быть и хорошо написан и плохо, но это не влеяет на его работу.
Почему многие боятся легаси, да потому что любое изменение в большой проект без четкого понимания всей логики часто приводит к появлению новых багов. И даже с модульными UI проектами оно так бывает, вот есть компонент кнопки, ок, меняем его, получаем что требовалось, а потом гневные возгласы заказчика, почему поменяли кнопку там где не требовалось и вообще почему в эту часть кода лезли )))
У меня по legacy такие мысли с точки зрения фронтендера.
Любой код превращается в legacy c течением времени из-за развития проекта и изменение технологического стека / подходов к разработке.
И нужно стремиться к уменьшению количества самого кода.
Пример развития проекта с работы.
1. NX Монорпеозиторий
У нас было 3 хостовых приложения и 50 модулей (отдельные страницы) к ним в отдельных репозиториях.
Мы приняли решение перейти на NX монорепозиторий и объединить модули и хосты.
После объединения сразу появился лишний legacy код (в виде регистрации модулей и т.п.), который мы методично убрали. Ушли лишние webpack.config.js в модулях и т.п. Меньше файлов - меньше legacy.
2. Наш любимый React Redux
Мы приняли решение отказаться от redux в пользу локальных State по возможности и заменой его на легковесный zustand и React Context.
Каждый модуль уменьшился процентов на 30-50 legacy кода, который был из-за Redux boilerplate.
Модули сами по себе остались legacy без изменения бизнес логики.
Не получится полностью избавится от legacy, но можно существенно сократить его объём.
У нас было 3 хостовых приложения и 50 модулей (отдельные страницы) к ним в отдельных репозиториях.
Хорошо когда объемы небольшие и есть время все это регулярно переписывать на "модный в этом сезоне стек".
Когда у вас в команде будет сотни репозиториев с десятками и более объектов в каждом, а ресурсы разработчика будут планироваться на 2 и более квартала вперед (это только по плановым проектным задачам, не считая срочных - дефекты промсреды, "нормативка"...), а каждый разработчик будет параллельно тянуть по 2-3 задачи, вам станет не до этих развлечений.
Год 2030. Чат джпт 11 на каждом углу.
Разработчики не пишут код сами. Открывают какой-нибудь хелло ворлд забавы ради и такие фу Легаси, уродливое. Да кто так пишет вообще.
Надо же в чат отправить "Напиши мне хелло ворлд с тестами"
Почему код становится legacy?