В вычислительной технике устаревшая система — это старый метод, технология, компьютерная система или прикладная программа , «относящиеся к предыдущей или устаревшей компьютерной системе или являющиеся ею», [1] , но все еще используемые. Частое упоминание системы как «устаревшей» означает, что она проложила путь для стандартов, которые последуют за ней. Это также может означать, что система устарела или нуждается в замене.
Устаревший код — это старый исходный код компьютера , который больше не поддерживается стандартным оборудованием и средами, и представляет собой кодовую базу, которая в некотором отношении устарела или поддерживает что-то устаревшее. Устаревший код может быть написан на языках программирования, использовать фреймворки и внешние библиотеки или использовать архитектуру и шаблоны, которые больше не считаются современными, увеличивая умственную нагрузку и время наращивания для инженеров-программистов, работающих над кодовой базой. Устаревший код может иметь нулевые или недостаточные автоматизированные тесты , что делает рефакторинг опасным и может привести к появлению ошибок . [2] Долгоживущий код подвержен программной гнили , когда изменения в среде выполнения или окружающем программном обеспечении или оборудовании могут потребовать обслуживания или эмуляции какого-либо рода для продолжения работы. Устаревший код может присутствовать для поддержки устаревшего оборудования, отдельной устаревшей системы или устаревшего клиента, использующего старую функцию или версию программного обеспечения.
Хотя этот термин обычно относится к исходному коду, он также может применяться к исполняемому коду, который больше не работает в более поздней версии системы или требует для этого слоя совместимости . Примером может служить классическое приложение Macintosh , которое не будет работать изначально в macOS , но будет работать внутри Classic environment , или приложение Win16, работающее в Windows XP с использованием функции Windows on Windows в XP.
Примером устаревшего оборудования являются устаревшие порты , такие как порты PS/2 и VGA, а также процессоры со старыми, несовместимыми наборами инструкций (например, с новыми операционными системами). Примерами устаревшего программного обеспечения являются устаревшие форматы файлов , такие как .swf для Adobe Flash или .123 для Lotus 1-2-3 , и текстовые файлы, закодированные устаревшими кодировками символов , такими как EBCDIC .
Первое использование термина legacy для описания компьютерных систем, вероятно, произошло в 1960-х годах. [3] К 1980-м годам он стал широко использоваться для обозначения существующих компьютерных систем, чтобы отличать их от проектирования и внедрения новых систем. Legacy часто можно было услышать во время процесса преобразования, например, при перемещении данных из устаревшей системы в новую базу данных.
Хотя этот термин может указывать на то, что некоторые инженеры могут считать систему устаревшей, устаревшая система может продолжать использоваться по разным причинам. Это может быть просто потому, что система все еще обеспечивает потребности пользователей. Кроме того, решение сохранить старую систему может быть принято под влиянием экономических причин, таких как проблемы возврата инвестиций или привязка к поставщику , неотъемлемые проблемы управления изменениями или множество других причин, отличных от функциональности. Обратная совместимость (например, способность новых систем обрабатывать устаревшие форматы файлов и кодировки символов ) — это цель, которую разработчики программного обеспечения часто включают в свою работу.
Даже если устаревшая система больше не используется, она может продолжать оказывать влияние на организацию из-за своей исторической роли. Исторические данные могли не быть преобразованы в новый системный формат и могут существовать в новой системе с использованием настраиваемого переходного схемного перехода или могут существовать только в хранилище данных . В любом случае влияние на бизнес-аналитику и операционную отчетность может быть значительным. Устаревшая система может включать процедуры или терминологию, которые больше не актуальны в текущем контексте, и могут затруднять или запутывать понимание используемых методов или технологий.
У организаций могут быть веские причины для сохранения устаревшей системы, например:
Некоторые инженеры-программисты считают устаревшие системы потенциально проблемными по нескольким причинам. [4]
Там, где невозможно заменить устаревшие системы посредством практики вывода приложений из эксплуатации , их все еще можно улучшить (или «переделать»). Большая часть разработки часто идет на добавление новых интерфейсов к устаревшей системе. Наиболее известным методом является предоставление веб-интерфейса для терминального приложения мэйнфрейма. Это может снизить производительность персонала из-за более медленного времени отклика и более медленных действий оператора на основе мыши, однако это часто рассматривается как «обновление», поскольку стиль интерфейса знаком неопытным пользователям и прост для них в использовании. Джон Маккормик обсуждает такие стратегии, которые включают промежуточное программное обеспечение . [10]
Улучшения печати проблематичны, поскольку устаревшие программные системы часто не добавляют инструкций по форматированию или используют протоколы, которые не могут использоваться в современных принтерах ПК/Windows. Сервер печати может использоваться для перехвата данных и перевода их в более современный код. Документы в формате Rich Text Format (RTF) или PostScript могут быть созданы в устаревшем приложении, а затем интерпретированы на ПК перед печатью.
Биометрические меры безопасности трудно реализовать на устаревших системах. Работоспособным решением является использование Telnet или HTTP- прокси-сервера для размещения между пользователями и мэйнфреймом для реализации безопасного доступа к устаревшему приложению.
Изменения, предпринимаемые в некоторых организациях, заключаются в переходе на программное обеспечение автоматизированных бизнес-процессов (ABP), которое генерирует полные системы. Затем эти системы могут взаимодействовать с устаревшими системами организаций и использовать их в качестве хранилищ данных . Такой подход может обеспечить ряд существенных преимуществ: пользователи изолированы от неэффективности своих устаревших систем, а изменения можно быстро и легко вносить в программное обеспечение ABP.
Подходы к обратному и прямому проектированию на основе моделей также могут использоваться для улучшения устаревшего программного обеспечения. [11]
Андреас М. Хайн исследовал использование устаревших систем в исследовании космоса в Мюнхенском техническом университете. По словам Хайна, устаревшие системы привлекательны для повторного использования, если у организации есть возможности для проверки, валидации, тестирования и истории эксплуатации. [12] [13] Эти возможности должны быть интегрированы в различные фазы жизненного цикла программного обеспечения, такие как разработка, внедрение, использование или обслуживание. Для программных систем решающее значение имеет возможность использовать и обслуживать систему. В противном случае система будет становиться все менее и менее понятной и обслуживаемой.
По словам Хайна, проверка, валидация, тестирование и история эксплуатации повышают уверенность в надежности и качестве системы. Однако накопление этой истории часто обходится дорого. В ныне закрытой программе Space Shuttle НАСА использовалось большое количество технологий 1970-х годов. Замена была непомерно дорогой из-за дорогостоящего требования к сертификации полета. Оригинальное оборудование выполнило дорогостоящее требование по интеграции и сертификации для полета, но любому новому оборудованию пришлось бы снова пройти весь этот процесс. Этот длительный и подробный процесс требовал обширных испытаний новых компонентов в их новых конфигурациях, прежде чем отдельный блок мог быть использован в программе Space Shuttle. Таким образом, любая новая система, которая начала процесс сертификации, становится де-факто устаревшей системой к моменту ее одобрения для полета.
Кроме того, вся система Space Shuttle, включая наземные и пусковые активы, была разработана для совместной работы как закрытая система. Поскольку спецификации не изменились, все сертифицированные системы и компоненты хорошо работали в тех ролях, для которых они были разработаны. [14] Еще до того, как Shuttle был запланирован к выводу из эксплуатации в 2010 году, NASA посчитало выгодным продолжать использовать многие части технологий 1970-х годов, а не модернизировать эти системы и повторно сертифицировать новые компоненты.
Некоторые специалисты по программной инженерии предпочитают описывать «устаревший код» без коннотации устаревания. Среди наиболее распространенных нейтральных концепций — исходный код, унаследованный от кого-то другого , и исходный код, унаследованный от более старой версии программного обеспечения . Эли Лопиан, генеральный директор Typemock, определил его как «код, который разработчики боятся менять». [15] Майкл Фезерс [16] представил определение устаревшего кода как кода без тестов , что отражает точку зрения, что с устаревшим кодом трудно работать отчасти из-за отсутствия автоматизированных регрессионных тестов . Он также определил характеристические тесты , чтобы начать подвергать устаревший код тестированию.
Джинни Хендри охарактеризовала создание кода как «вызов» для нынешних кодеров, который должен создать код, который «похож на другие наследия в нашей жизни — как антиквариат, семейные реликвии и истории, которые лелеются и с любовью передаются из поколения в поколение. Что, если бы унаследованный код был чем-то, чем мы гордились бы?». [17]
Термин « поддержка устаревших версий » часто используется в сочетании с устаревшими системами. Термин может относиться к функции современного программного обеспечения. Например, операционные системы с «поддержкой устаревших версий» могут обнаруживать и использовать устаревшее оборудование. Термин также может использоваться для обозначения бизнес-функции; например, поставщика программного обеспечения или оборудования, который поддерживает или обеспечивает обслуживание программного обеспечения для устаревших продуктов.
«Устаревший» продукт может быть продуктом, который больше не продается, потерял значительную долю рынка или является версией продукта, который не актуален. Устаревший продукт может иметь некоторое преимущество перед современным продуктом, что делает его привлекательным для клиентов, чтобы сохранить его. Продукт является по-настоящему «устаревшим» только в том случае, если он не имеет преимущества ни для кого — если ни один человек, принимающий рациональное решение, не захочет приобрести его новым.
Термин «устаревший режим» часто относится именно к обратной совместимости . Программный продукт, способный работать так, как если бы он был предыдущей версией самого себя, называется «работающим в устаревшем режиме». Такая функция распространена в операционных системах и интернет-браузерах, где многие приложения зависят от этих базовых компонентов.
В эпоху мэйнфреймов многие приложения работали в устаревшем режиме. В современной среде бизнес-вычислений n-уровневые или 3-уровневые архитектуры сложнее перевести в устаревший режим, поскольку они включают в себя множество компонентов, составляющих единую систему.
Технология виртуализации — это недавнее новшество, позволяющее устаревшим системам продолжать работать на современном оборудовании, запуская старые операционные системы и браузеры на программной системе, которая эмулирует устаревшее оборудование.
Программисты заимствовали термин «браунфилд» из строительной отрасли, где ранее освоенные земли (часто загрязненные и заброшенные) описываются как «браунфилд» . [18]
Существует и альтернативное благоприятное мнение, которое стало распространяться после окончания пузыря доткомов в 1999 году: устаревшие системы — это просто компьютерные системы, находящиеся в рабочем состоянии:
« Устаревший код » часто отличается от предлагаемой альтернативы тем, что он действительно работает и масштабируется.
— Бьёрн Страуструп, создатель C++
Аналитики ИТ оценивают, что стоимость замены бизнес-логики примерно в пять раз превышает стоимость повторного использования, [19] даже без учета риска сбоев системы и нарушений безопасности. В идеале компаниям никогда не придется переписывать большую часть основной бизнес-логики: дебеты = кредиты — это постоянное требование.
IT-индустрия отвечает «модернизацией наследия» и «трансформацией наследия»: обновлением существующей бизнес-логики с помощью новых пользовательских интерфейсов, иногда с использованием скрапинга экрана и сервисного доступа через веб-сервисы . Эти методы позволяют организациям понимать свои существующие активы кода (используя инструменты обнаружения), предоставлять новые пользовательские и прикладные интерфейсы для существующего кода, улучшать рабочий процесс, сдерживать затраты, минимизировать риски и пользоваться классическими качествами обслуживания (почти 100% времени безотказной работы, безопасность, масштабируемость и т. д.). [20]
Эта тенденция также побуждает задуматься о том, что делает устаревшие системы такими долговечными. Технологи заново осознают важность надежной архитектуры с самого начала, чтобы избежать дорогостоящих и рискованных переписываний. Наиболее распространенными устаревшими системами, как правило, являются те, которые охватывают известные принципы архитектуры ИТ с тщательным планированием и строгой методологией во время внедрения. Плохо спроектированные системы часто не служат долго, как потому, что они изнашиваются, так и потому, что их неотъемлемые недостатки требуют замены. Таким образом, многие организации заново открывают для себя ценность как своих устаревших систем, так и теоретических основ этих систем.
Медиа, связанные с Legacy systems на Wikimedia Commons