Легаси: поддерживать нельзя переписать

Алексей Рузин

Team Lead Python

«Легаси» — это слово, которым программисты пугают друг друга (и менеджеров). Оно означает устаревший софт, работать с которым обычно сложно и/или неприятно по причине небольшого «выхлопа» в пересчете на вкладываемые усилия. Обобщив, словом «легаси» можно назвать любой «код», который сложно поддерживать. И чем сложнее, тем он более «легаси».

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

Неважно, как хорошо и чисто написан код — рано или поздно он станет легаси.

А что плохого в легаси?

Основные недостатки легаси для бизнеса, это:

• низкое соотношение пользы к вложенным усилиям на изменения;
• медленные изменения;
• сложности с подбором команды для работы над кодом.

Причины, по которым появляется легаси

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

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

В другую группу можно отнести низкую культуру или плохую организацию процесса разработки.

Так незафиксированные требования к программному продукту могут и будут приводить к конфликтам между пользователями и разработчиками (и даже внутри группы разработки). По мере развития ПО необходимо вносить изменения и в документацию.

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

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

Выбраны неподходящие технологии (СУБД, фреймворки, библиотеки, или сторонние сервисы); не учтены особенности масштабирования.

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

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

Сюда же отнесем плохо организованный проект: нет системы контроля версий; отсутствие задачника (системы фиксации запросов на изменения к системе); нет связи между коммитами и задачами (требованиями);

Отсутствие людей, которые имеют навык поддержки кода продукта, также делает код более “легаси”.

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

Легаси с «положительной обратной связью»

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

Почему легаси неохотно заменяют

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

Минутка математики!
Можно представить, что легаси L(t) — это неотрицательная функция от времени. Пусть скорость разработки S(t) = F(L(t)), где F — некоторая функция, которая учитывает влияние легаси на скорость разработки при прочих постоянных факторах. Точный вид F неизвестен, но для нее верно: чем больше “легаси”, тем меньше скорость разработки, а при легаси равной 0 скорость максимальная F(0) = Fmax.
При этом польза компании V определяется как интеграл от затрачиваемых ресурсов:
V = ∫K·S(t)dt, где K — это сумма, которую бизнес готов вложить в разработку софта за интервал времени.
Если К представить в виде суммы Ks (деньги на пользу) и Kl (деньги на борьбу с легаси), такие, что Ks + Kl = K, то, зная форму F, можно максимизировать V для компании.
И вот эта задача, которую в том числе решает СТО – определить форму F и максимизировать V ?

Однако поддержка системы может столкнуться с внезапной проблемой, например: в сторонней библиотеке обнаружена уязвимость. А библиотека не поддерживается и обновлений не будет. Вариантов решения может быть много: устранить проблему своими силами, заменить библиотеку, построить какое-то безопасное окружение, отказаться от функционала и пр.

Бывают случаи, когда легаси «починке/доработке» не подлежит, только замене. В такой ситуации перед бизнесом встанет выбор:

• отказаться от доработок (если это возможно);
• отказаться от доработок в текущей системе и начать разработку новой;
• перейти на готовое стороннее решение.

Одна из главных задач СТО — минимизировать риски возникновения «внезапных проблем» и иметь план действий в случае их наступления.

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

СТО заблаговременно должен отслеживать тенденции на рынке и продумывать план внедрения новых технологий в свои системы или планировать переход на другие решения, оценивая стоимость разных вариантов.

Как бороться с Легаси

• выделять время на мониторинг индустрии. Если какие-то технологии или ПО устаревают, надо планировать переход на новые технологии / обновление ПО;
• организовать процесс разработки так, чтобы требования были четкие и зафиксированы в какой-то системе, чтобы изменения в коде были привязаны к этим требованиям;
• покрывать систему тестами;
• следить за актуальностью документации;
• приостанавливать разработку и проводить рефакторинг кода в случаях, когда костылей становится слишком много (здесь важен баланс, так как постоянный рефакторинг в борьбе за «скорость разработки» отнимает время от разработки);
• передавать владение кода от программиста к программисту: 1) больше людей знакомы – меньше рисков, что код остается бесхозным, 2) отработанная практика передачи владения стимулирует поддерживать код и документацию в надлежащем виде (в процессе передачи будут выявляться недостатки), придает уверенность, что новый человек сможет разобраться;
• следить за чистотой кода (как минимум настроить линтеры, проводить ревью).

Польза от Легаси

Итак, легаси присутствует в той или иной степени во всех компаниях, где есть разработка. Так какова же польза от него? Для бизнеса пользы никакой — при прочих равных, чем больше легаси, тем для компании хуже, уменьшение или поддержание легаси на заданном уровне стоит денег, поэтому каждая компания определяет этот уровень самостоятельно (конечно же, не по формулам выше, а по интуиции, но как-то определяет).

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

Если вы «застряли» в какой-то технологии, не отчаивайтесь, возможно, через несколько лет, вы станете редким высокооплачиваемым специалистом. ?

В США ряд старых банковских систем написаны на COBOL — устаревшем языке программирования. Поддерживать системы надо, а молодые специалисты не горят желанием изучать этот язык, поэтому специалистов не хватает. Ситуация настолько накалилась, что энтузиаст COBOL создал собственную компанию по оказанию экстренной поддержки банкам и обучению молодежи языку, что вслед за ним сделало и IBM.

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