Что такое legacy система

Что такое легаси в коде

Иногда программисты на вопрос, почему программа работает именно так, отвечают, что это «легаси» и исправить ничего нельзя. Разберёмся, что это значит, насколько это мешает разработке и что делают с легаси-кодом.

Что такое легаси

С английского legacy переводится как «наследие». Легаси-код — это код, который перешёл «по наследству» от предыдущих разработчиков. Чаще всего это происходит так:

1. Команда делает продукт, внутри много разных возможностей.
2. Часть функций со временем оптимизируется, а часть остаётся неизменной в виде старого кода, потому что и так работает.
3. Некоторое время спустя в команде не остаётся тех, кто писал старый код.
4. Текущая команда не знает, почему старый код написан именно так.
5. В этих кусках сложно что-то поменять или разобраться, потому что всё остальное написано уже по-другому.
6. Этот старый код, который сложно поддерживать и сложно разбираться — это и есть легаси.

�� Проще говоря, легаси — это код, про который говорят: «Это ещё Михалыч писал 8 лет назад для синхронизации с сервером, он работает, мы его не трогаем, потому что иначе всё сломается». При этом Михалыча в компании давно нет, документации тоже нет, и проще этот код не трогать совсем.

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

Откуда берётся легаси

Причин появления легаси может быть несколько:

• команда перешла на другой фреймворк, но части программы остались на старом;
• часть программы написана на старой версии языка;
• старая команда не задокументировала свой код;
• код написан в одном стиле, а команда давно перешла на другой стиль программирования.

Легаси — это не какое-то преступление, а часть жизни любой живой ИТ-компании. Рано или поздно у любого продукта появится легаси. И чем крупнее проект, тем больше его будет. Например, в исходном коде Windows 10 до сих пор остаются фрагменты кода, написанные ещё 20 лет назад для Windows 3.1.

Легаси — это плохо?

Легаси — это просто старый код, который нужно поддерживать наравне с новым. Если он работает — отлично, пусть живёт. Другое дело, что команде, например, было бы удобнее, чтобы код был написан не на старом фреймворке, а на новом, который знают все.

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

Что значит «поддерживать старый код»?

Например, в старом коде для запроса к серверу идёт сначала адрес, а потом номер запроса. Спустя 10 лет требования сервера изменились, поэтому сначала должен идти запрос, а потом уже адрес. Значит, нужно изменить порядок полей в коде.

Если старый код понятен и хорошо задокументирован, на эту задачу уйдёт две минуты. Если это старые пыльные легаси-кишки, то это может стать задачей на час.

Что делать с легаси-кодом

Если легаси-код работает и не требует вмешательства и поддержки — то можно пока ничего не делать, пусть работает. Будет время — перепишем на новый фреймворк, а если нет, то и так пока поработает.

А если нужно срочное вмешательство — пахнет бедой. Зовите менеджеров.

Курсы по программированию с нуля

Приходите к нам в ИТ. У нас есть удаленная работа, высокие зарплаты и удобное обучение в «Яндекс Практикуме». Старт бесплатно.

Получите ИТ-профессию

В «Яндекс Практикуме» можно стать разработчиком, тестировщиком, аналитиком и менеджером цифровых продуктов. Первая часть обучения всегда бесплатная, чтобы попробовать и найти то, что вам по душе. Дальше — программы трудоустройства.

Почему код становится legacy?

Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б.

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

Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.

Теперь давайте заставим эти препятствия двигаться. Медленно, но достаточно для того, чтобы вызвать проблемы с необходимостью переподключения точек. Это уже не такая простая прямая линия, и начинает выглядеть куда серьезнее.

А если мы заставим двигаться не только препятствия, но и сами точки? Вдобавок убедимся, что эти точки не приклеены к линиям, и вам придется следить за ними, чтобы они оставались соединенными. Начинает немного бесить?

Но и это еще не всё. Представьте, что мы знаем лишь приблизительное положение точек, и единственный способ узнать его — запрашивать их местоположение каждые 5 минут? Походит на безумие, или еще нет?

Усложним еще немного. Допустим, мы знаем только приблизительное положение точек.

Вот это уже в значительной степени похоже на то, как происходит разработка в реальном мире.

Обсуждение

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

Препятствия могут быть ограничениями в технологии, производительности, программировании, различными процессами и всем остальным, что может встать на нашем пути. Всегда есть что-то, с чем мы как решатели проблем уже привыкли сталкиваться.

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

Такой код известен как legacy — код, который очень сложно изменить без полного краха и который обходится так же дорого, как и полная перепись с нуля.

Да, с классической точки зрения, легаси — это старый код, который нужно поддерживать как internet explorer, или код, написанный человеком, который уже не работает в вашей компании.

Но в современном обиходе этот термин более широкий и обозначает плохой ломкий код.

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

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

Как решить эту проблему?

Частично она решается с помощью так называемых шаблонов проектирования — точечных решений, которые мы можем собрать вместе, подобно конструктору Лего, чтобы сделать процесс быстрее и более контролируемым.

Но шаблонов проектирования недостаточно. Гораздо важнее знать, что мы быстро движемся в правильном направлении, нежели правильно двигаемся в неправильном. И да, в мире полно устаревшего кода, который следует лучшим шаблонам проектирования. Фактически, чрезмерное использование шаблонов проектирования сверх необходимого называется «оверинжинерингом».

Мы должны как можно быстрее узнавать, где находятся точки из нашего примера, и для этого нам нужен автоматизированный мгновенный способ получения обратной связи. В этом помогает тестирование вашего кода. Да, не каждый тест подходит, но тестирование по стратегии черного ящика специально проверяет именно точки, а не какие-то части по пути.

В общем, чтобы решить проблему постоянно меняющегося положения точек и препятствий, нам нужно выполнить два условия:

1. Как можно быстрее узнавать, что мы быстро движемся в правильном направлении (обратная связь о правильности в виде черного ящика тестов)
2. Использовать заранее продуманные решения для быстрого и контролируемого построения пути (шаблоны проектирования).

Что в итоге

Эти два пункта выше очень просто звучат, но их не так-то просто достигнуть в контексте разработки пользовательского интерфейса, чем мы и попытаемся заняться в этом цикле статей.

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

Почему разработка пользовательского интерфейса особенно склонна к Legacy?

Используя метафору с линией из примера выше, мы пришли к определению того, что такое legacy-код:

Legacy-код — это код, который очень сложно изменить, ничего не сломав в процессе, и его переписывание обходится так же дорого, как написание с нуля.

Такой код появляется, когда у нас есть сложные и постоянно меняющиеся ограничения и требования, обратная связь о корректности задерживается, а объем кодовой базы — постоянно растет.

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

Дисклеймер: Все приведенные ниже примеры являются выдуманными, упрощенными и нужны только для иллюстрации — любое сходство с реальными людьми случайно.

От идеи до legacy

Greenfield — проект одного человека, создаваемый с нуля

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

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

Итак, вы начинаете работать над проектом, настраиваете конфигурации и прочее. Но как только этот этап остается позади, игра начинается — теперь вы создаете.

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

С некоторыми неудачами (мы же с вами в реальном мире живем) вы справляетесь. Всё сделано вовремя, все довольны.

Проект Brownfield

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

Вам будет гораздо сложнее понять мыслительный процесс человека, который создавал приложение до вас. Как он думал, что делал, зачем. Скорее всего, он не обращал много внимания на что-то, кроме требований, поэтому тестирования тут будет мало (если оно вообще будет). А логика будет куда более запутанной из-за упрощения разработки.

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

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

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

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

Шаг за шагом, и кодовая база станет тем, что называется legacy.

Legacy-проект

И даже пример выше не такой печальный, как самая частая ситуация — работа над legacy-проектом в качестве разработчика.

Здесь почти нет надежды на рефакторинг устаревшей части. Цикл обратной связи для большинства приложений будет ощутимо задерживаться, а процесс покрытия приложения тестами всегда будет отставать и подрывать мотивацию.

Заключение

Разработка пользовательского интерфейса подвержена устареванию, потому что быстрая обратная связь и эффективные шаблоны проектирования, позволяющие обеспечить модульность, не включаются в проект на этапе его создания с нуля.

Далее в цикле:

• Так как же сделать пользовательский интерфейс легкотестируемым и легкоизменяемым?
• Decoupler MVU или как реализовать MVU архитектуру для UI приложений

Полезные ссылки

1. Black Box Testing: An In-Depth Tutorial — Этот туториал на Guru99 предоставляет всестороннее руководство по тестированию черного ящика. В нем рассматриваются его методы, типы, приемы, преимущества и недостатки.
2. Design patterns — Подробное руководство по шаблонам проектирования программного обеспечения. Каждый шаблон подробно объясняется с примерами, чтобы лучше понять, когда и где их использовать.
3. SOLID Principles: Explanation and examples — Этот пост на FreeCodeCamp разбирает принципы SOLID в понятной форме с большим количеством примеров.
4. Understanding Legacy Code: Этот сайт — отличный источник информации для понимания legacy-кода и стратегий эффективной работы с ним. Поможет вам ориентироваться и улучшать legacy-системы.
5. Greenfield vs Brownfield: В этой статье на LinkedIn Giorgi Bastos подробно рассматривает концепции проектов greenfield и brownfield. Автор дает отличное представление о различиях, преимуществах и вызовах обоих подходов.
6. Greenfield vs Brownfield in Software Development: Synoptek предоставляет подробное сравнение между разработкой программного обеспечения greenfield и brownfield, дополнительно улучшая понимание этих концепций и их влияния на разработку пользовательского интерфейса.
7. Advantages and Disadvantages of White Box Testing: На JavaTpoint опубликовано сбалансированное представление о тестировании белого ящика и подробное обсуждение его преимуществ и ограничений.
8. White Box Testing: Pros and Cons: Segue Technologies предлагает другую точку зрения на тестирование белого ящика, подробно описывая его плюсы и минусы. Эта статья поможет вам понять, почему тестирование белого ящика может быть частью проблемы при поддержке кода пользовательского интерфейса.

• философия программирования
• програмирование
• легаси
• legacy
• поддержка кода
• UI

• Блог компании билайн
• Программирование
• Совершенный код
• Дизайн

Укрощая зверя: legacy-код, тесты и вы

Legacy-код — это «старый» код, возраст которого может быть как 2 месяца, так и 10 лет. Часто его писали разработчики, о которых в компании смутно помнят. Возможно, их вообще не было, а legacy-код родился вместе со Вселенной во время Большого Взрыва. С тех пор требования к нему менялись много раз, код правили в режиме «нужно было еще вчера», а документацию никто не писал, как и тесты. Legacy-код запутан и хрупок, в нем не видно ни начала, ни конца. Как к нему подступиться?

Здесь и далее кадры из сериала «Рик и Морти». Авторы Джастин Ройланд и Дэн Хармон.

Подбираться к нему нужно с тестов, но готовьтесь к боли. Проблемы начнутся уже с того момента, как вы решите взяться за такой проект. Вам нужно понять, зачем вы хотите за него браться, убедить руководство одобрить тестирование legacy-кода, а коллег — помочь. После этого возникнут вопросы, с чего начать изучение, какие тесты запустить первыми и как все не сломать? Но главное — как не впасть в отчаяние, когда поймете, что работе нет конца.

Кирилл Борисов 12 лет в индустрии, за эти годы прошел долгий путь по костылям, битому коду и гниющим каркасам старых систем: от монолитных учетных систем до микросервисов авторизации. Путешествие наградило его опытом и историями, которыми он поделится в виде ценных советов.

У меня есть мечта — когда-нибудь поработать над новым проектом. В нем все будет хорошо с самого начала и свежо, как первый снег: тесты, архитектура и смысл. Но это лишь мечта, потому что уже 10 лет я продаю свой талант за деньги и перехожу из одного legacy-проекта к другому.

За это время у меня не осталось нервов, но я могу сберечь ваши, поделившись своим опытом взаимодействия с legacy. Я расскажу, как укрощать зверя (legacy-код): работать с кодом и людьми, внедрять тестирование, нужно ли это делать и как к этому относятся и разработчики.

Чего здесь не будет:

• Советов, как писать тесты. Множество книг, статей и разных видео закрывают этот вопрос.
• Обсуждения методологий. BDD, TDD, ATDD — все на ваше усмотрение.
• Всего, что может нарушить NDA. У людей долгая память, а у юристов — длинные руки.

Что такое legacy-код

Определений много. Я считаю, что это «достаточно старый» код возрастом от 2 месяцев до 10 лет. Legacy-код запутан и хрупок, но как гигантский змей пожирает свой хвост.

Именно это не позволяет начать его спокойно тестировать. Все разработчики, от начинающих до опытных, когда приходят на legacy-проект, хватаются за копье тестов и несутся убивать это чудовище. Копье ломается, а вместе с ним люди. В итоге остается разработчик без признаков жизни, который работает на legacy-проекте десятки лет.

Возможно ли побороть этого зверя? Да, но нужна подготовка.

Подготовка

Борьба со зверем не так важна, как подготовительный этап. Он начинается с трех вопросов самому себе.

«Зачем я это делаю?» Серьёзно, зачем? Ведь варианта всего два.

• Вы хотите славы, чтобы люди говорили, как вы великолепны, потому что внедрили тесты.
• Чтобы облегчить жизнь себе, коллегам и компании.

«Знаю ли я, что делаю?» Если вы писали тесты, то знаете. Если нет, то прежде чем бросаться на монстра, овладейте азами: напишите 3-4 теста, покройте небольшую часть кода, набейте руку и почувствуйте силу.

«Есть ли у меня на это время?» Замечательнос благими порывами вмешиваться в код и улучшать его, работая на будущее. Но, возможно, на это нет времени, когда горит настоящее. Если так, то проекту нужны вы, а не светлый образ будущего.

Когда вы ответите на все вопросы утвердительно — переходите к следующему этапу.

Разведка местности

Изучите структуру проекта. У вас есть представление о структуре проекта, составных частях и принципе работы? Наверняка да, но, возможно, оно не совпадает с реальностью. Важно понимать, с чем придется столкнуться перед началом работы. Посвятите немного времени, чтобы пройтись по проекту и изучить его досконально.

Составьте схему зависимостей. Ни один проект не живет в вакууме. Базы данных, внешние сервисы, библиотеки — все это может использоваться в проекте.

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

После разведки переходим к боевым действиям.

Борьба с организацией

Первый раунд — борьба с вашей организацией. Главный в ней — ваш менеджер, непосредственный начальник.

Менеджер. Он не так страшен, как кажется. Это обычный человек с обычными потребностями: сдать проект вовремя и без лишних проблем, получить за это деньги и бонусы и жить дальше.

Руководитель не против ваших начинаний. Он против того, чтобы вы кидались на проект с криками: «Тесты! Тесты! Тесты!». Если будете так делать, он посмотрит на вас как на человека, который тратит его время и тормозит остальных.

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

Тест не стоит подавать так:

— О, это будет круто!

Свои идеи надо продвигать так:

— В прошлом квартале у нас было 50 падений, которые можно было исправить на стадии разработки продукта. Исправить можно с помощью тестов. Они подтвердят, что внесённые изменения не изменили функционал, если мы того не ожидаем. Мы сэкономим часы, потраченные на устранение этих проблем и снизим сумму неустойки, которую выплатили из-за неработающей системы.

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

Proof of Concept повышает шансы. Предоставьте менеджеру отдельный изолированный участок кода, подсистему, которая покрывается тестами, запускается и работает. Это можно сделать, если взять один из наболевших багов, который всплывает с определенной периодичностью и попытаться его отловить и устранить тестом. PoC подтвердит ваши намерения, покажет, что у вас есть план и ваша работа приносит результат.

Не обещайте много. Для менеджера важны цифры: какие результаты, сроки и какими силами. Но менеджер — существо жадное до результатов. Не обещайте слишком много с самого начала. Если пообещаете решить все проблемы сразу, менеджер пойдет с этим к начальству. Начальство скажет: «Замечательно!», но сократит финансирование и срежет сроки в надежде, что мы сдадим систему намного раньше.

Когда договоримся с менеджером, переходим к тем, с кем приходится работать каждый день.

Коллеги

Не любят перемены. Типичный коллега на типичном legacy-проекте — это человек, который потерял веру в жизнь и будущее. Он не склонен к изменениям и смирился с судьбой: «Я здесь навсегда, выхода из болота нет». Проблема в том, что вы начинаете мутить воду в этом болоте. Вы требуете, чтобы он писал и запускал какие-то тесты, а он хочет выполнить свою работы, закрыть задачу и уйти домой.

Заинтересуйте коллег пользой — объясните, почему им станет лучше. Например, они постоянно тратят время и силы, оставаясь после работы, чтобы залечить какие-то баги. Надавите на это: «Если не деплоить на продакшн сломанный код, не придется тратить время на его починку. Напишем тесты, будем вылавливать такой код, меньше будет ломаться».

Проявите терпение и эмпатию. Вы общаетесь с людьми — спросите почему их беспокоит ваша идея? Предложите найти точку соприкосновения, чтобы понять друг друга. В этом основная тактика работы с людьми: не враждуйте, не сталкивайтесь лбами, будьте дружелюбнее.

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

Для решения этой проблемы есть один грязный трюк. К сожалению, в своей жизни я пользовался им не раз.

Разделяйте и властвуйте. Подойдите к одному из коллег за обедом или в уголке и скажите: «Вся команда уже подписалась, ты один тормозишь процесс. Может быть, мы найдем общий язык?»

Пройдя всех по очереди вы подпишите всех. Всем будет стыдно признаться, что они подумали, что все остальные уже подписались. Это бесчестно и ужасно, но работает. Используйте этот прием ответственно и в крайнем случае. Помните — вам еще работать с этими людьми.

Когда разобрались с коллегами, нас ждет еще один жадный зверь.

Борьба с машиной

Это хитросплетение кода, которое называется продуктом. Начнем с азов.

Разберите хлам. Тестировать необходимо так, чтобы при минимальном воздействии на систему получать проверяемый результат. Но любая legacy-система полна данными: они добавлялись годами с момента запуска и влияют на поведение системы. Поэтому необходимо тестировать «с чистого листа».

Подготовьте «сферическую систему в вакууме»: опустошите источники данных, сделайте минимальные конфиги, которые запускает система, отключите все возможные «хаки» и «фичи». Заставьте систему запуститься. Если запустится — у вас есть минимальный набор данных, который необходим для функционирования. Это уже хорошая отправная точка — «чистый лист».

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

Распутайте данные. Любой legacy-проект работает на принципе «надо сдать вчера». Все, что вы проходили в университете или читали в книгах, здесь не работает. Когда начнете тестировать, столкнетесь, например, с циклической зависимостью, невозможной для воссоздания в программе, но необходимой для функционирования.

Начните с «главного объекта». Чтобы разобраться с лесом зависимостей, попробуйте задуматься о том, какой объект главный. Например, для системы учета склада главный объект — «ящик». С ним связан объект «полка», а с «полкой» — объект «ряд».

Воссоздайте необходимый минимум. Если смотреть по ссылкам между объектами и переходить всё глубже по дереву зависимостей, вы сможете определить необходимый минимум данных зависимых объектов. Вам его нужно воссоздать, чтобы система работала и могла функционировать для тестирования вашего функционала.

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

Переходим к тестированию. Для запутанных старых продуктов хорошая стратегия — это smoke-тесты.

Smoke-тесты

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

В информационных системах концепция smoke-тестов достаточно простая. Представим веб-сервис, у него есть endpoint. Попробуем отправить ему GET-запрос без параметров. Если по какой-то причине продукт неожиданно сломался (ошибка 500), то что-то пошло не так.

Smoke-тест — хорошее начало. Это тест, который проверяет некоторую функциональность и дает понять, что система работает или сломана. Даже простой запрос к самому простому endpoint уже затрагивает больше 1% кода. Такими небольшими тестами готовим плацдарм для дальнейшего тестирования.

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

Используйте такую тактику, чтобы покрыть несколько основных точек входа в вашу программу: форму ввода логина/пароля, основные веб-сервисы, кнопки. Это что-то уже можно показать менеджеру и коллегам.

Функциональные тесты

Это не тесты отдельных классов или метод, а самый высокий возможный уровень тестирования определенной части функционала.

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

Покрытие основного функционала подобными тестами позволяет быстро стартовать и сразу покрывает большие участки. Вы будете уверены, что код работает хотя бы приблизительно так, как вы представляете, приобретете больше уверенности, набьете руку и вскроете еще больше проблем.

Функциональные тесты — средство, а не цель.

На иглу функциональных тестов легко подсесть: «Я же тестирую реальный функционал! Это то, с чем сталкиваются пользователи».

Функциональный тест задействует большие куски кода, которые могут взаимодействовать с гигантскими объемами данных. Поэтому 3-4 функциональных теста — это хорошо, 10 хуже, а тысячи тестов, проходящие 9 часов, — перебор. К сожалению, такое тоже бывает.

После функциональных тестов беритесь за unit-тесты. Но о них я не буду рассказывать — вы и так все знаете.

Мы прошлись по азам машинного тестирования и возвращаемся к основной теме. Коллеги и менеджер — не самый страшный враг в бою с legacy. Самый страшный враг — вы сами.

Борьба с собой

Будьте готовы к тому, что путь будет казаться бесконечным. Работа на неделю в вашем плане займет полгода без перспектив завершения проекта.

Сопротивление неизбежно. Все союзники со временем начнут сомневаться, пытаться сойти с колеи, уговаривать бросить тесты и перейти к фичам. Будьте к этому готовы. Напомните всем, зачем вы вообще во все это ввязались, сколько сил и времени вложено. Слабый аргумент, но может сработать.

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

Это нормально, это не конец жизни и карьеры. Это даже не подтверждение того, что вы плохой профессионал. Единственный вывод здесь, что конкретно этот проект завершился неудачей.

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

Теперь обидное, горькое и вечное.

Напутствия

Не бойтесь обратной связи. Мне приходилось наступать в эту ловушку и видеть, как в нее попадают другие. Я что-то сделал и принес похвалиться коллегам: «Я сделяль!» Но неожиданно оказывается, что мой удобный механизм неудобен коллегам, а я и не спрашивал.

Пишите тесты, пробуйте то, что внедряете. Часто внедрение нового тестового фреймворка увлекает, а непосредственно сами тесты вы не пишите. Тогда может случиться так, что как только их напишите, поймете, что не сможете воспользоваться тестами. Возможно, коллеги тоже это видят, но молчат, либо просто не пишут тесты.

Помогайте коллегам с проблемами, даже если они об этом не просят. Помощь не означает взять всю работу на себя — это расслабляет коллег и снимает с них ответственность, а «автобусное» число снижается до единицы.Тогда вы становитесь человеком-тестировщиком: что-то сломалось, CI красный, тест-гайд. Помогайте в рамках разумного.

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

Улучшайте механизмы тестирования. Многих проблем можно избежать просто потому, что медленные тесты неожиданно стали быстрыми. Раньше они занимали 20 строк кода, а теперь одну. Вы этого не замечали, потому что один раз что-то написали и забыли: «Работает — не трогай!» Но это правило не всегда применимо.

Вы — не центр Вселенной. Снова повторю, что «автобусное» число это не шутка. Не раз сталкивался с ситуацией, когда человек начал тестирование, а потом получил предложение в проект посвежее: все бросил, убежал, а комментариев и документации не оставил. Все работает до нового коммита, а починить невозможно — никто не понимает, как все устроено.

Не хочу, чтобы вы оказались этим человеком. Не превращайтесь в ограничивающий фактор.

• Пишите документацию.
• Проводите тренинги.
• Распространяйте свой опыт.

27 марта на Moscow Python Conf++ Кирилл расскажет о технической стороне рефакторинга кода с Python 2 на Python 3 — что может быть актуальнее в 2020 году.

Что еще нас ждёт на конференции, можно посмотреть в статье с обзором программы или в соцсетях (fb, vk, twitter) и telegram-канале мероприятия. Скоро увидимся!

• python
• legacy
• рефакторинг
• тесты
• smoke tests
• функциональное тестирование
• moscow python conf++

What is a Legacy System and Why Are They in Use?

Kevin McGahey — July 18, 2023

“Legacy system” is a phrase that professionals use a lot, and it has a lot of negative connotations. Some businesses feel they need to avoid legacy systems at all costs, while others find that most of their major operations depend on outdated software or processes. But even though a business may find older systems that run legacy applications are essential, it’s time to consider whether the risks are worth it.

Here are the key things to know about legacy systems:

• Legacy systems are outdated software or hardware that are still in use due to their historical significance, cost considerations, stability, and criticality to business processes.
• Legacy systems can be challenging to scale, may lack compatibility with modern technologies, and can pose security risks due to a lack of support and updates.
• However, legacy systems are important for preserving historical business processes, retaining valuable data, ensuring business continuity, and providing customers with a familiar experience.
• The risks and disadvantages of legacy systems include scalability limitations, security vulnerabilities, compatibility issues, and difficulties in finding qualified developers.
• Migrating legacy systems can be done through methods like rip and replace, lift and shift, or gradual improvement and moving. Data migration practices involve extracting, transforming, cleansing, and validating the data to ensure a smooth transition to a new system.

Table of Contents

• What are Legacy Systems?
• How Do Legacy Systems Work?
• Why are Legacy Systems Important?
• Types of Legacy Systems
• Legacy System Examples
• Should You Upgrade a Legacy System?
• Migrating Legacy Systems
• Frequently Asked Questions: What is a Legacy System?

Generate a full-featured, documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

What are Legacy Systems?

A legacy system may be old or relatively new. The most important distinction is that it is in some way outdated, lacking modern support or features. The phrase may refer to either software or hardware.

A legacy system will often be incompatible with modern formats, no longer offer updates, or lack the opportunities for extendability that newer systems have.

In short, a legacy system hasn’t caught up with the changing needs of a modern company. That is why it is so important to understand them: so that companies can remain at the cutting edge of technology and serve their industry to the best of their ability.

The United States government is known for keeping old technology in place to run agencies like the IRS and the Social Security Administration. A new bill may put an end to the practice, however. The risk of security breaches and maintenance costs make legacy systems a burden in both the public sector and private businesses.

A significant portion of budgets goes to maintaining IT systems that are already obsolete. An estimated 70% of enterprise data runs through outdated mainframe systems. As companies struggle to keep up with the changing times, it is important to comprehend the systems that uphold your essential processes. A legacy system is more than just old software.

What exactly are legacy systems, and is it worthwhile for your enterprise to replace them? This article will help you decide.

How Do Legacy Systems Work?

Legacy systems often rely on proprietary programming languages, hardware, or software that may no longer be widely supported or used in modern environments. They tend to have custom-built components and configurations specific to the organization’s historical requirements, making them challenging to upgrade or replace. These systems may lack integration capabilities with newer technologies and struggle to communicate with modern applications or platforms.

Legacy systems typically operate in a centralized manner, with data stored in on-premises servers or mainframes. They follow monolithic architectures, where all functionalities and modules are tightly coupled. This structure makes it difficult to modify or add new features without impacting the system’s stability or requiring extensive rework. Maintenance and troubleshooting can be complex, as the codebase may lack proper documentation and comprehensive understanding.

Despite their limitations, legacy systems continue to be used for several reasons. Organizations may have invested substantial resources in developing and maintaining these systems over the years, making it difficult to justify a complete overhaul. Additionally, legacy systems often handle critical business processes, and the risks associated with replacing them, such as potential disruptions and data migration challenges, can be daunting. Moreover, organizations may face budget constraints or lack the necessary expertise to migrate to modern technologies, leading to the continued use of legacy systems.

Why are Legacy Systems Important?

Legacy systems have their limitations and challenges, but they continue to play a significant role in many organizations. Here are some reasons why legacy systems are important:

1. Historical Business Processes: Legacy systems often contain the knowledge and logic of critical business processes that have evolved over time. These systems have been customized to meet specific organizational needs and can handle complex workflows efficiently. They have built-in business rules and workflows that reflect the organization’s unique operations. Replacing a legacy system means re-engineering these processes, which can be time-consuming and resource-intensive.
2. Data Retention and Compliance: Legacy systems often store vast amounts of historical data accumulated over years or even decades. This historical data can be valuable for various purposes, such as compliance audits, historical analysis, and legal requirements. Migrating this data to a new system while preserving its integrity and ensuring compliance with data protection regulations can be a complex and challenging task.
3. Cost Considerations: Replacing a legacy system with a modern alternative can be a substantial investment. It involves not only the cost of new hardware and software but also the expenses associated with data migration, system integration, training, and potential business disruptions during the transition. For some organizations, the cost of replacing a legacy system may outweigh the benefits, especially if the system continues to meet their immediate operational needs.
4. Stability and Reliability: Legacy systems, despite their age, can be highly stable and reliable. Over the years, organizations have fine-tuned and optimized these systems to ensure consistent performance and minimize downtime. The familiarity and expertise gained by IT staff in managing and maintaining legacy systems contribute to their stability and reliability.
5. Business Continuity: Legacy systems have often been the backbone of an organization’s operations for a significant period. They have proven their ability to support critical business processes and have built a level of trust within the organization. Replacing a legacy system entails a certain level of risk, as it may disrupt operations, require retraining of staff, and introduce unfamiliarity with new processes and interfaces.

Types of Legacy Systems

What are some types of legacy systems that companies are using?

End of Life. End of Life (EOL) legacy systems are systems that, from the vendor’s perspective, are now past the useful stage. As a result, the vendor discontinues the product. They have dropped support and no longer offer the product. One example is Microsoft dropping support for old operating systems like Windows 7 and Windows XP.

No updates available. While this relates closely to EOL, you can often replace an EOL legacy system with a similar but updated solution, or as in the case of Windows, a vendor may offer a newer version that performs similarly. Some legacy software, however, has no updates or newer versions to offer. This can make it difficult for businesses to change since they may have to switch to a new vendor and work with new processes to perform the same tasks.

Unable to scale. Some software systems cannot scale sufficiently to support, for instance, larger streams of data or a bigger volume of financial transactions. The software has already become obsolete for a growing company.

Heavily patched. The more patches that software has required in the past, the more difficult it can be to keep up with security concerns. Over the years, the software may become increasingly vulnerable, especially after the vendor has dropped support and no longer creates new patches or monitors old issues.

Lack of qualified developers. If a company does software development or has customized software in-house, finding qualified developers who can maintain the software may be difficult or nearly impossible. If a company depends on the legacy system for everyday processes, this can be a huge problem. One example is a company using legacy applications written in programming languages that only a few people in the enterprise can use or edit.

Legacy System Examples

There are two primary examples of legacy computer systems that remain in use:

Legacy financial systems. While fintech (financial technology) is a growing and vibrant industry, most banks nonetheless rely on outdated software systems to perform transactions. They may have been using some of the outdated systems for many years without making any substantial changes.

Legacy databases. Legacy databases and data-related software are major concerns for businesses. For instance, legacy systems are costing companies revenue simply by making large amounts of data inaccessible through outdated infrastructure.

Should You Upgrade a Legacy System?

Business owners may feel the need to review their legacy systems based on what the competition is doing, or perhaps they are struggling to give clients the experience they need. Additionally, they may wonder if legacy systems are saving them money or if they are actually costing them money. What are some of the pros and cons of legacy systems?

Benefits of Legacy Systems

Durable. A legacy system can be notoriously durable. They can last 10 to 30 years without substantial changes, supporting essential business processes. This makes them virtually indispensable for many companies. One example is Windows XP, which was in use for many years after Microsoft dropped support. In fact, some businesses still use XP today, despite potential concerns.

Gives customers what they’re used to. This may be a primary concern for many service-based enterprises. A big advantage is giving customers a consistent experience without major changes to functionality over the years. Client experience is one of the biggest factors in which brand customers choose to use. The last thing an enterprise wants to do is alienate customers by completely changing the experience. This is also significant for long-time customers who have always interacted with the brand in the same way. A change can create turnover and other inconveniences.

While these pros may be consequential, there are also some significant disadvantages to using a legacy system.

Problems With Legacy Systems

Many think the list is a mile wide, but a couple of the problems associated with old systems are especially important.

Scalability. Legacy systems can be incredibly difficult, if not impossible, to scale as your company grows. This is particularly troublesome when considering systems such as ETL software and data warehouses. Data is constantly flowing into companies, and as your company grows, so does the amount of data that you need to process. Data solutions must be able to scale with this data, or they will hold your company back.

Security. American businesses lose money to data breaches at an alarming rate. A majority of breaches are due to available patches but unapplied. In the case of legacy software, vulnerabilities often go undetected due to a lack of support. If you can detect them, they may not have a patch available. If a patch is available, it may be challenging to find someone who can apply it, or it may be extremely costly. The longer these systems are in use, the more security concerns there are.

Compatibility. Outdated technology lacks the capabilities of a new system. This can mean a lack of compatibility with the latest internet technology or an inability to utilize modern security measures.

Unforeseen issues. The risk of keeping legacy systems around has only increased in the last couple of years, thanks to novel attacks coordinated by hacker groups. Modern consumer applications, which tend to be scrutinized for security less than enterprise applications, have provided a gateway for malicious code to make its way to legacy systems. A report from security experts detailed how TikTok could be used as a vehicle to exploit lingering security issues in older, unpatched systems. Since many enterprise employees use smartphones and other devices in the workplace, this presents a new attack vector that information security teams may not even consider. This scenario is an excellent example of why legacy systems need to be seriously evaluated for their value versus the unknown risk they may bring. On the other hand, modern systems continually receive security updates. Threats like these new techniques can be patched, often before IT staff would have to deal with the exploit.

Migrating Legacy Systems

Based on the problems with legacy systems, it might seem reasonable to migrate old systems immediately. However, migrating from legacy systems also comes with certain issues.

There may be a variety of reasons why legacy migration fails. Perhaps a business tries to do too much at once, or perhaps the new technology they plan to implement doesn’t work out. That is why companies must carefully choose how they want to migrate. There are three main methods:

Rip and Replace

This phrase refers to simply destroying and replacing outdated software or system that is outdated. It is the fastest way to modernize, but it is also highly disruptive. In the case of rewriting a legacy application using modern programming languages and methods, the rip-and-replace method may introduce unexpected complexities. Legacy applications often support essential business processes in a code base that may be millions of lines. Without a thorough examination of the business practices and procedures that depend on a legacy application, rip and replace might cause the most problems of any of these methods.

Lift and Shift

Lift and shift migration simply moves an application or data to the cloud. It is fairly simple and can add some new life to an application. The lack of well-documented legacy code is the biggest roadblock to a successful lift and shift operation. Documentation for code that has been in use for years or decades is essential for understanding why changes were made and what functions are supported. If the system you are looking at replacing is so old that it runs on mainframe assembly code, a lift and shift may not even be possible.

Improve and Move

This is a more gradual solution that improves or rebuilds parts of the architecture of a system or application. This method has become more prevalent in recent years due to the more straightforward change management process it offers. Variations of this method can be used in conjunction with the other two techniques.

Understanding legacy systems and legacy system migration are important, but so is finding a company that can help throughout the process.

Generate a full-featured, documented, and secure REST API in minutes.

Sign up for our free 14 day hosted trial to learn how.

DreamFactory and Legacy Systems

One of the main risks of not modernizing is that, in many cases, the competition already has or has strategies underway to do so. This gives them a competitive advantage that may be hard to match.

DreamFactory offers many options for bringing legacy systems up to date. With DreamFactory, you can:

• Bring extended technology lifecycles through building real-time interfaces to legacy environments.
• Add modern security to legacy platforms instantly, solving vulnerabilities in previously unprotected APIs through authentication, role-based access controls and volume limiting.
• Integrate mainframes and modern application environments using the Scripted Services connector as a bridge. This solution offers tight integration with Python, Ruby, PHP and NodeJS scripting environments.
• Create a REST API. You can replace legacy APIs easily with a secure, standardized, fully documented and reusable REST API.
• Additionally, DreamFactory can help you manage your data portfolio. Using our services, you can de-risk legacy system replacements.

With so many costs to analyze and so many legacy tools that you may need to replace, it can be difficult to begin the process of modernization. With cutting-edge API solutions, DreamFactory can lead your company through the next steps of legacy migration.

On the other hand, not updating systems comes with a risk. Companies have to balance the potential problems with the potential gains of finding new solutions to give them the competitive edge they need in order to succeed. Contact DreamFactory today to receive a free hosted trial and a free tour of the platform and to learn more about how you can bring your business up to date in a rapidly evolving tech world.

Frequently Asked Questions: What is a Legacy System?

What is a legacy system?

A legacy system refers to outdated software or technology that is still in use within an organization. These systems were typically developed years ago using older programming languages, architectures, and hardware.

Why are legacy systems still in use?

Legacy systems are still in use for various reasons. One main reason is the significant investment made in their development and maintenance over the years. Replacing them can be costly and time-consuming. Legacy systems also often contain critical business logic and processes that have been tailored to an organization’s specific needs, making them difficult to replace without a major overhaul.

What are the challenges of using legacy systems?

Legacy systems can present several challenges. They may lack modern features and capabilities, making it harder to keep up with evolving business requirements. Technical support and expertise for legacy systems may also become scarce as newer technologies gain prominence. Additionally, legacy systems may be more vulnerable to security threats and may have compatibility issues with newer hardware or software.

Can legacy systems be modernized?

Yes, legacy systems can be modernized through various approaches. This may involve updating the system’s infrastructure, migrating to newer platforms, or implementing modernization techniques such as encapsulation or integration with newer systems. Modernization helps extend the life of legacy systems and brings them closer to contemporary standards and technologies.

When should organizations consider replacing legacy systems?

Organizations should consider replacing legacy systems when the cost and risks associated with maintaining and using them outweigh the benefits. Factors such as system performance, scalability, security vulnerabilities, and the availability of support and resources should be considered when evaluating the need for replacement. Organizations should also assess if a new system can provide better functionality, improved efficiency, and long-term sustainability.

What are the potential risks of using legacy systems?

Legacy systems can pose risks such as limited compatibility with modern technologies, increased security vulnerabilities, higher maintenance costs, and difficulties in integrating with newer systems. As technology continues to advance, organizations relying on legacy systems may find it challenging to keep pace with competitors and meet evolving customer demands.

Can legacy systems coexist with modern systems?

Yes, legacy systems can coexist with modern systems through integration and hybrid approaches. This allows organizations to gradually transition functionality from legacy systems to newer ones while maintaining business continuity. Integration strategies include leveraging APIs, data synchronization, and service-oriented architectures to bridge the gap between legacy and modern systems.

How can organizations mitigate the risks associated with legacy systems?

Organizations can mitigate risks by implementing proper maintenance and security practices for legacy systems. This includes regular updates and patches, implementing additional security measures, and conducting regular risk assessments. Legacy system modernization strategies can also help mitigate risks by gradually transitioning to newer technologies while preserving critical functionality and knowledge embedded in the legacy systems.

Kevin McGahey is an accomplished solutions engineer and product lead with expertise in API generation, microservices, and legacy system modernization, as demonstrated by his successful track record of facilitating the modernization of legacy databases for numerous public sector organizations.