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