Комментарии 21
Надо бы посчитать, что выгодней бизнесу - постоянно держать штат программистов, которые переписывают рабочий код стараясь держать его в тренде, или раз заплатить, и через 20 лет еще раз заплатить...
Вот возьмем спецов по коболу: этим гадам уже один раз заплатить не получается, они садятся на пожизненную зарплату :)
Спасибо, полезная и актуальная статья. А теперь интересно было бы послушать примеры реального лечения избавления от легаси на примере относительно крупной компании. Это был бы супер актуальный и интересный кейс.
В любом достаточно крупном проекте от легаси в принципе нельзя избавиться полностью. Пока заканчиваешь переписывать одно, устаревает второе. А еще фичи делать надо когда-то.
Зато можно поддерживать количество и состояние легаси кода приемлимым. Иногда лазить в него, местами рефакторить. Не боятся обновлять или фичи прикручивать. Или модным мониторингом все обвесить. Или вот как сейчас на jdk17 перевести все. Если на это выделять время у вас всегда будут разработчики которые ориентируются во всем легаси кода и поддерживают его в приемлимом состоянии.
Плата за это - некоторое уменьшение скорости разработки новых фич. На длинной дистанции плюсов больше как мне кажется.
Банк Содружества Австралии и Океании в 2012-м году решил полностью избавиться от легаси в своем коде.
Заняло это у них 5 лет (до 2017-го года). Обошлось в $750млн. Количество людских ресурсов неизвестно.
Больше желающих заменить проверенный десятилетиями работающий код в большой mission-critical системе не нашлось.
Известный случай с "падением серверов" службы занятости в США тоже оказался не в пользу замены легаси. Расследование выявило, что сами сервера с их легаси кодом работали как часы. Все проблемы были на middle слоях. Там, где использовались "современные стеки". Именно они оказались неготовыми к резко возросшей нагрузке.
Ну и правильно отмечено - если вы начинаете в большом легаси переходить на современный стек - будьте готовыми к тому, что к тому времени, когда вы разберетесь как оно работает, все перепишете, проведете все необходимые ретесты и внедрите, ваш "современный когда-то стек" уже превратится в то же легаси, от которого вы пытались избавиться.
Проблема на самом деле не в легаси. Проблема в недостаточной документированности процессов. Если все описано и документировано, да еще и архитектура изначально выбрана правильно, то абсолютно неважно когда и на чем оно написано.
А "избавление от легаси" часто объясняется просто - "я не хрена не понимаю как оно работает, дай-ка перепишу все по-своему". Это типичное велосипедостроение и хреносозидательство.
Кобол таки пора переписывать. Разработчиков уже нет, а через 10 лет (примерный срок завершения переписывания больших систем если начать завтра) вообще не будет. Нанять и и обучить тоже сложно. Мало кто хочет даже за оплату выше рынка.
Я бы оценил лет в 30 срок когда точно пора переписывать. Лучше через 20 уже начать плотно думать об этом и бюджет выделять. Чтобы через 30 точно закончить.
С кобол разработчиками не все так плохо. Просто это достаточно замкнутый мир. Это не джависты, которые прыгают с проекта на проект. Разработка на кобол требует более глубоких знаний, во-первых, платформы, на которой все это крутится т.к. платформы там достаточно специфические и требования к эффективности тоже достаточно высокие (а если человек хорошо знает платформу, то освоить кобол тело техники) и, во-вторых, более глубокого вникания в предметную область т.к. там сосредоточена вся бизнес-логика в которую так или иначе приходится вникать для достижения требуемой эффективности.
В общем, это отдельный мир где специалистов ищут или прямым хантингом или через знакомых. А отнюдь не публикацией вакансии на каком-нибудь hh. В крайнем случае поиск будет внутри специализированных групп на LinkedIn.
Это как бы "устрицы". С коболом дела не имел, но плотно работаю с его альтернативой - RPG. Ситуация именно такая.
Ну и найти замену коболу достаточно сложно - он разрабатывался специально под максимально эффективную по скорости и ресурсам реализацию коммерческой бизнес-логики. Реальная альтернатива - тот же RPG. Со всеми его специфическими возможностями (числовые типы с фиксированной точкой, работа со строками, прямой доступ к таблицам БД, возможность интеграции SQL непосредственно в код и т.п.)
Ну и объемы... Та же АБС (автоматизированная банковская система) это сотни тысяч, если не миллионы строк кода, 80 и более процентов которого составляют бизнес-логику и вообще не имеют никакого интерфейса (работают исключительно в фоне). Да еще и реализованы в модели близкой к модели акторов. Т.е. охватить разумом всю последовательность действий, которая возбуждается по изменению одного поля в какой-то таблице может оказаться очень и очень сложно.
И весь этот код работает очень давно. И из него вычищено за время работы 99.(9)% дефектов.
Плюс неизбежно возникнут головные боли типа "вот в таблице это поле прописано как timestamp, в коде с ним работают как с char, я пытаюсь сделать так же, но оно у меня даже не компилируется".
Плюс надо очень хорошо знать сам кобол чтобы понимать все тонкости работы кода, который переписываешь.
Т.е. мало все это понять как работает, мало все это переписать, надо еще провести полный ретест (а это компонентное, бизнес, нагрузочное и интеграционное тестирование на предмет неухудшения - оно не должно потреблять больше и не должно работать медленнее оригинала). Пример банка Австралии тому хороший показатель.
В общем, я не знаю так ли оно нужно. Есть ли сейчас действительно новые языки, ориентированные именно на коммерческие расчеты и глубоко интегрированные в платформы, на которых все это работает (т.е. которые дают реально быстрый и эффективный код).
По поводу "легаси" (правда, не языков, а платформ) давно ведутся споры - стоит ли мигрировать. Вот есть статейки на эту тему:
Классическая история: Герой убивает Дракона и сам становится драконом )))
Специалисты по устаревшим языкам и технологиям обходятся дорого
Судя по тому, что на Delphi, например, никто не предлагает рейтов в разы выше тех, что на популярных языках платятся, да и на саппорт-девелоперских вакансиях тоже не наблюдается избытка $$$, это утверждение мимо тазика.
Шел 2021, уже пару месяцев как вышел Delphi c поддержкой Windows 11 и M1, но люди все еще продолжали хоронить его. :)
С одной стороны, я ещё пользуюсь изредка Delphi и считаю его недооценённой на текущий момент системой. С другой - давайте будем честны с собой - Borland сама похоронила Delphi много лет назад, а сейчас всё никак не может реабилитировать стюардессу в глазах нового поколения.
Шел 2021, уже пару месяцев как вышел Delphi c поддержкой Windows 11 и M1, но люди все еще продолжали хоронить его. :)
У кобола тоже компиляторы в 21 году выходят с обновлениями и всякими ф-циями
а люди всё продолжают его хоронить
Выходить он может хоть для калькулятора МК-85, но где вакансии с в разы большей оплатой, чем для Java/NET?
Программисты на COBOL'е в США вышли из чата
Legacy - То чувство, когда проект над которым работаешь находится на стадии "казнить, нельзя помиловать", но правки всё равно нужно вносить...
Я все понимаю, но зачем вы логотип у Half-Life взяли?
"Требуется Программист 1С 7.7" ;)
Взгляд на легаси со стороны «пассажира»