Legacy: поддерживать нельзя переписать
Легаси (от англ. legacy — наследие) — реальность любого программиста. Объясняем, как софт становится легаси и почему это нормально, а также какие существуют плюсы при работе с легаси. Не всегда стоит относиться к легаси как к проклятию, стоит взглянуть на него как на естественный этап жизненного цикла программного обеспечения. Меня зовут Алексей Рузин, я уже более 20 лет в разработке, поработал с разными проектами (новыми и не очень), преподавал Python в GeekBrains и Яндекс Практикуме. Про легаси я знаю не понаслышке Последние 10+ лет одним из моих проектов является сложная ERP-система для работы с клиентами, проектам, документами и финансами
«Легаси» — это слово, которым программисты пугают друг друга (и менеджеров). Оно означает устаревший софт, работать с которым обычно сложно и/или неприятно по причине небольшого «выхлопа» в пересчете на вкладываемые усилия. В целом, словом «легаси» можно назвать любой «код», который сложно поддерживать. И чем сложнее, тем он более «легаси».
Сегодня расскажем, откуда он берется, как удерживать его «в рамках» и чем он может быть полезен для начинающих специалистов.
Неважно, как хорошо и чисто написан код — рано или поздно он станет легаси.
А что плохого в «легаси»?
Основные недостатки «легаси» для бизнеса, это:
низкое соотношение пользы к вложенным усилиям на изменения;
медленные изменения;
сложности с подбором команды для работы над кодом.
Вот, например, отличная статья, в которой CTO LinguaLeo (сервис и приложение для изучения языков) рассказывает о проблемах, которые заставили их перейти на новые технологии: «В карантин нагрузка выросла в 5 раз, но мы были готовы». Как Lingualeo переехал на PostgreSQL с 23 млн юзеров
Причины, по которым появляется «легаси»
Список предпосылок условно делится на две группы: на те, что не зависят от команды и те, на которые можно повлиять. К первым можно отнести устаревание технологий, операционных систем, языков программирования, протоколов, библиотек, фреймворков, да и подходов к проектированию систем (например, при появлении новых возможностей, скажем, многоядерные процессоры). Под устареванием понимается, то, что на смену им приходят новые технологии, позволяющие достигать результата быстрее или дешевле. Вся индустрия на них постепенно переключается, и если не идти в ногу с ней, то программный продукт становится легаси.
В другую группу можно отнести и низкую культуру или плохую организацию процесса разработки. Так, например, незафиксированные требования к программному продукту могут и будут приводить к конфликтам между пользователями и разработчиками (и даже внутри группы разработки). По мере развития ПО необходимо вносить изменения и в документацию. Отсутствие такой практики будет приводить к тем же проблемам. Пользователи будут сильно зависеть от экспертизы разработчиков. А если последние уволятся, то восстановления знаний из кода, хоть и возможно, но обычно это долгий и трудоемкий процесс в результате которого остается много вопросов «почему так сделали?» или «зачем это?».
Неверная архитектура или плохо спроектированный код провоцируют написание «костылей» (плохое решение, на момент написания которого, мы знаем что с ним будут или могут быть проблемы в будущем, однако которое решает проблему «здесь и сейчас»). Обсуждению архитектуры и проектирования можно посвятить отдельную статью или даже книгу, но если коротко, то нарушение общепринятых практик написания ПО, в частности 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;)
Однако поддержка системы может столкнуться с внезапной проблемой, например: в сторонней библиотеке обнаружена уязвимость. А библиотека не поддерживается и обновлений не будет. Вариантов решения проблемы может быть много: устранить проблему своими силами, заменить библиотеку, построить какое-то безопасное окружение, отказаться от функционала и пр.
Бывают случаи, когда легаси «починке/доработке» не подлежит, только замене. В такой ситуации перед бизнесом встанет выбор:
отказаться от доработок (если это возможно)
отказаться от доработок в текущей системе и начать разработку новой
перейти на готовое стороннее решение
Одна из главных задач СТО — минимизировать риски возникновения «внезапных проблем» и иметь план действий в случае их наступления.
Готовиться к переходу на новую систему нужно заранее, как правило это занимает много времени (и денег). Нужно перенести данные и, главное, обучить людей работе в новой системе, что, часто связано с изменением внутренних процессов. А такие изменения никто не любит.
СТО заблаговременно должен отслеживать тенденции на рынке технологий и продумывать план внедрения новых технологий в свои системы или планировать переход на другие решения, оценивая стоимость разных вариантов.
Фронтенд нашей внутренней самописной ERP-системы построен 2009-м году на основе ExtJS (на тот момент — лидер среди фреймворков для написания SPA-приложений). Кроме поддержки и развития основной ERP-системы нашей команде требовалось разрабатывать отдельные вспомогательные небольшие сервисы. На наш взгляд ExtJS для них не очень подходил по двум причинам: ограничения вызванные визуальной частью (вы из коробки получаете набор готовых элементов, но они стандартные, а их кастомизация — это головная боль), и второе вложения на первоначальном этапе разработке приложения выше, чем при походе HTML+CSS+JQuery. Немного помучавшись с технологиями «каменного века» в 2013–14-м годах мы начали поиски альтернативных фреймворков/библиотек и нашли AngularJS, ReactJS, MeteorJS, позже к ним еще добавилась vue.
Получив опыт разработки на каждой технологии в течение 2–3-х лет, а также оглядываясь на рынок (где ReactJS является лидером) определились и большинство новых сервисов уже разрабатываем на ReactJS. Даже новые части в нашей ERP-системе разрабатываем с использованием ReactJS. При этом следует отметить, что основная часть ERP остается на ExtJS, т.к. ее замена на ReactJS не принесет столько выгоды, во сколько обойдется замена.
Как бороться с Легаси
Выделять время на мониторинг индустрии. Если какие-то технологии или ПО устаревают, надо планировать переход на новые технологии / обновление ПО;
Организовать процесс разработки так, чтобы требования были четкие и зафиксированы в какой-то системе, чтобы изменения в коде были привязаны к этим требованиям;
Покрывать систему тестами;
Следить за актуальностью документации;
Приостанавливать разработку и проводить рефакторинг кода в случаях, когда «костылей» становится слишком много (здесь важен баланс, так как постоянный рефакторинг в борьбе за «скорость разработки» отнимает время от разработки);
Передавать владение кода от программиста к программисту: 1) больше людей знакомы — меньше рисков, что код остается бесхозным, 2) отработанная практика передачи владения, стимулирует поддерживать код и документацию в надлежащем виде (в процессе передаче будут выявляться недостатки), придает уверенность, что новый человек сможет разобраться;
Следить за чистотой кода (как минимум настроить линтеры, проводить ревью).
Польза от Легаси
Итак, «легаси» присутствует в той или иной степени во всех компаниях, где есть разработка. Так какова же польза от него? Для бизнеса пользы никакой нет — при прочих равных, чем больше легаси, тем для компании хуже, однако уменьшение или поддержание легаси на заданному уровне стоит денег, поэтому каждая компания определяет этот уровень самостоятельно. (Конечно же не по формулам выше, а по интуиции, но как-то определяет).
Однако польза от легаси может быть для сотрудников, с ней работающих. Особенно для новичков приходящих в компанию. Во-первых, уровень зарплаты может быть выше, если вы не первый, кто устраивается работать с «их легаси». Компания может удерживать разработчиков, чтобы их код кто-то поддерживал. Во-вторых, уровень стресса может быть ниже, если компания привыкла к медленным внедрениям (оговорка, не везде и не всегда). Плюс сомнительный, но для кого-то это может показаться более комфортным местом. В-третьих, есть возможность изучить поглубже определенные технологии, используемые в этой компании — все равно «легаси» изучать, можно и документацию по технологиям почитать. Особый плюс для стажеров и джунов, которым нужно первое место работы — если в компании, готовы их взять и помогать разбираться с кодом, даже решая простые задачи в сложной системе — это может быть отличным стартом карьеры. Еще один плюс — можно посмотреть, как делать НЕ надо ;-)
Если вы «застряли» в какой-то технологии, не отчаивайтесь, возможно через несколько лет, вы станете редким высокооплачиваемым специалистом. :)
В США ряд старых банковских систем написаны на COBOL — устаревшем языке программирования. Поддерживать системы надо, а молодые специалисты не горят желанием изучать этот язык, поэтому специалистов не хватает. Ситуация настолько накалилась, что энтузиаст COBOL создал собственную компанию по оказанию экстренной поддержки банкам и обучению молодежи языку, что вслед за ним сделало и IBM.
В общем, от легаси никуда не денешься. Оно всё равно будет появляться и с ним предстоит жить и бороться. Это стоит воспринимать как вызов. Или как возможность, если вы ещё на старте карьеры.
