Программное обеспечение гниет
Процесс ухудшения программного обеспечения

Гниение программного обеспечения ( битовая гниль , гниение кода , эрозия программного обеспечения , распад программного обеспечения или энтропия программного обеспечения ) — это деградация, ухудшение или потеря возможности использования или производительности программного обеспечения с течением времени.

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

Jargon File , сборник хакерских знаний, определяет «битовую гниль» как шутливое объяснение деградации программного обеспечения с течением времени, даже если «ничего не изменилось»; идея, лежащая в основе этого, почти такая же, как если бы биты, составляющие программу, подвергались радиоактивному распаду. [1]

Причины

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

Изменение окружающей среды

Запись экрана с ошибкой, появившейся в Blender 2.9 в результате изменений в драйверах AMD , вызывающих стробирующие точки света и неправильную визуализацию нормалей поверхности . Для учета этих изменений пришлось внести обновления в код Blender, исправив ошибку.

Когда в среде программы происходят изменения, особенно изменения, которые разработчик программы не предвидел, программное обеспечение может больше не работать так, как изначально предполагалось. Например, многие ранние разработчики компьютерных игр использовали тактовую частоту процессора в качестве таймера в своих играх. [2] Однако более новые тактовые частоты процессора были быстрее, поэтому скорость игрового процесса соответственно увеличивалась, делая игры менее удобными с течением времени.

Одиночество

Изменения в среде связаны не с разработчиком программы, а с ее пользователями. Изначально пользователь может привести систему в рабочее состояние и заставить ее работать безупречно в течение определенного времени. Но когда система перестает работать правильно или пользователи хотят получить доступ к элементам управления конфигурацией, они не могут повторить этот начальный шаг из-за другого контекста и недоступной информации (утерян пароль, отсутствуют инструкции или просто сложный в управлении пользовательский интерфейс , который был изначально настроен методом проб и ошибок). Информационный архитектор Йонас Сёдерстрём назвал эту концепцию onceability [3] и определяет ее как «качество в технической системе , которое не позволяет пользователю восстановить систему после того, как она вышла из строя».

Неиспользованный код

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

Редко обновляемый код

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

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

Онлайн-подключение

Современное коммерческое программное обеспечение часто подключается к онлайн-серверу для проверки лицензии и доступа к информации. Если онлайн-сервис, обеспечивающий работу программного обеспечения, закрыт, оно может перестать работать. [4] [5]

С конца 2010-х годов большинство веб-сайтов используют защищенные HTTPS- соединения. Однако для этого требуются ключи шифрования, называемые корневыми сертификатами, которые имеют даты истечения срока действия. После истечения срока действия сертификатов устройство теряет подключение к большинству веб-сайтов, если ключи не обновляются постоянно. [6]

Другая проблема заключается в том, что в марте 2021 года старые стандарты шифрования TLS 1.0 и TLS 1.1 были объявлены устаревшими . [7] Это означает, что операционные системы, браузеры и другое онлайн-программное обеспечение, которые не поддерживают как минимум TLS 1.2, не могут подключаться к большинству веб-сайтов, даже для загрузки исправлений или обновления браузера, если они доступны. Это иногда называют «TLS-апокалипсисом».

Продукты, которые не могут подключаться к большинству веб-сайтов, включают PowerMac, старые Unix-боксы и версии Microsoft Windows старше Server 2008/Windows 7 (по крайней мере без использования стороннего браузера). Браузер Internet Explorer 8 в Server 2008/Windows 7 поддерживает TLS 1.2, но он отключен по умолчанию. [8]

Классификация

Программное гниение обычно классифицируется как «спящее гниение» или «активное гниение».

Спящая гниль

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

Активная гниль

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

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

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

Примеры

Пример программы ИИ

Многие основополагающие программы из ранних дней исследований ИИ пострадали от непоправимой программной гнили. Например, оригинальная программа SHRDLU (ранняя программа понимания естественного языка) не может быть запущена ни на одном современном компьютере или компьютерном симуляторе, поскольку она была разработана в те дни, когда LISP и PLANNER все еще находились в стадии разработки, и поэтому использует нестандартные макросы и программные библиотеки, которые больше не существуют.

Пример разветвленного онлайн-форума

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

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

  • Администратор может случайно внести изменения, которые конфликтуют друг с другом или с исходным программным обеспечением, что приведет к неожиданному поведению форума или его полной поломке. Это ставит их в очень плохое положение: поскольку они так сильно отклонились от исходного кода, техническую поддержку и помощь в восстановлении форума будет трудно получить.
  • В исходном коде форума может быть обнаружена дыра в безопасности, требующая исправления безопасности. Однако, поскольку администратор так сильно изменил код, исправление может быть не применимо напрямую к его коду, требуя от администратора фактически переписать обновление.
  • Администратор, который внес изменения, может освободить свою должность, оставив нового администратора с запутанным и сильно измененным форумом, в котором отсутствует полная документация. Без полного понимания изменений новому администратору трудно вносить изменения, не внося конфликтов и ошибок. Более того, документация исходной системы может быть больше недоступна или, что еще хуже, вводить в заблуждение из-за тонких различий в функциональных требованиях.

Пример Вики

Предположим, что веб-мастер устанавливает последнюю версию MediaWiki , программного обеспечения, которое поддерживает вики, такие как Wikipedia, а затем никогда не применяет никаких обновлений. Со временем веб-хостинг, скорее всего, обновит свои версии языка программирования (например, PHP ) и базы данных (например, MariaDB ) без консультации с веб-мастером. По прошествии достаточно длительного времени это в конечном итоге сломает сложные веб-сайты, которые не были обновлены, потому что последние версии PHP и MariaDB будут иметь критические изменения, поскольку они жестко устарели некоторые встроенные функции , нарушая обратную совместимость и вызывая фатальные ошибки . Другие проблемы, которые могут возникнуть с необновленным программным обеспечением веб-сайта, включают уязвимости безопасности и спам .

Рефакторинг

Рефакторинг — это способ решения проблемы гниения программного обеспечения. Он описывается как процесс переписывания существующего кода для улучшения его структуры без влияния на его внешнее поведение. [9] Это включает удаление мертвого кода и переписывание разделов, которые были значительно изменены и больше не работают эффективно. Необходимо проявлять осторожность, чтобы не изменить внешнее поведение программного обеспечения, поскольку это может привести к несовместимости и, таким образом, само по себе способствовать гниению программного обеспечения. Некоторые принципы проектирования, которые следует учитывать при рефакторинге, — это поддержание иерархической структуры кода и реализация абстракции для упрощения и обобщения структур кода. [10]

Энтропия программного обеспечения

Энтропия программного обеспечения описывает тенденцию к исправлению и модификации программной системы, приводящую к постепенной потере ее структуры или увеличению сложности. [11] Мэнни Леман использовал термин «энтропия» в 1974 году для описания сложности программной системы и для проведения аналогии со вторым законом термодинамики . Законы эволюции программного обеспечения Лемана гласят, что сложная программная система будет требовать постоянных модификаций для поддержания своей релевантности окружающей среде, и что такие модификации будут увеличивать энтропию системы, если не будет выполнена определенная работа по ее снижению. [12]

Ивар Якобсон и др. в 1992 году описали энтропию программного обеспечения аналогичным образом и утверждали, что это увеличение беспорядка по мере модификации системы в конечном итоге всегда делает поддержку программной системы неэкономичной, хотя время, пока это произойдет, во многом зависит от ее первоначальной конструкции и может быть увеличено путем рефакторинга. [13]

В 1999 году Эндрю Хант и Дэвид Томас использовали починку разбитых окон в качестве метафоры для избежания программной энтропии при разработке программного обеспечения. [14]

Смотрите также

Ссылки

  1. ^ Рэймонд, Эрик. "Bit rot". Файл жаргона . Получено 3 марта 2013 г.
  2. ↑ Салеми, Джо (1992-01-28). Журнал PC. Ziff Davis, Inc. стр. 286.
  3. ^ Йонас Сёдерстрём. "Одновременность: Последствие технологического упадка". Архивировано из оригинала 03.06.2021.
  4. ^ Амадео, Рон (31 октября 2016 г.). «(Обновленная) история Android». Ars Technica . Получено 31 октября 2021 г.
  5. ^ "Adobe CS2 теперь доступен бесплатно, Sort Of". Mobile Magazine. 2013-01-14. Архивировано из оригинала 2013-01-18 . Получено 2013-01-20 .
  6. ^ Пол Вагенсейл (24.12.2020). «Апокалипсис отложен: эти устройства Android больше не будут выходить в офлайн следующей осенью». Tom's Guide . Получено 16.03.2023 .
  7. ^ "RFC ft-ietf-tls-oldversions-deprecate: Устаревание TLS 1.0 и TLS 1.1". IETF Datatracker . 2021-03-23 . Получено 2023-03-16 .
  8. ^ "Windows 7 добавляет поддержку TLSv1.1 и TLSv1.2 - IEInternals - Главная страница сайта - Блоги MSDN". Архивировано из оригинала 2013-12-26.
  9. ^ Фаулер, Мартин (11 октября 2007 г.). "Что такое рефакторинг" . Получено 22 ноября 2007 г.
  10. ^ Сурьянараяна, Гириш, Ганеш Самартьям и Тушар Шарма. Рефакторинг для запахов проектирования программного обеспечения: Управление техническим долгом / Гириш Сурьянараяна, Ганеш Самартьям, Тушар Шарма. 1-е издание. Уолтем, Массачусетс ; Морган Кауфманн, 2015. Печать.
  11. ^ Трипати, Приядарши; Наик, Кширасагар (2014). Эволюция и обслуживание программного обеспечения: подход практикующего специалиста. Хобокен, Нью-Джерси: Уайли. п. 376. ИСБН 978-0-470-60341-3.
  12. ^ Леман, ММ; Белади, Л.А. (1985), Эволюция программ: процессы изменения программного обеспечения , Academic Press, стр.  143–144 , ISBN 9780124424401
  13. ^ Джейкобсон, Ивар; Кристерсон, Магнус; Йонссон, Патрик; Овергаард, Гуннар (1992), Объектно-ориентированная разработка программного обеспечения: подход, основанный на сценариях использования , ACM Press. Аддисон-Уэсли, стр. 70–72, ISBN. 0-201-54435-0
  14. ^ Хант, Эндрю; Томас, Дэвид (1999), Прагматичный программист , Эддисон Уэсли, стр.  4–6 , ISBN 0-201-61622-X
Взято с "https://en.wikipedia.org/w/index.php?title=Software_rot&oldid=1269757144"