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

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

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

Причины

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

Изменения в среде

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

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

Одноразовость

Имеются изменения в окружающей среде, не связанные с разработчиком программы, а с её пользователем. Первоначально, пользователь мог привести систему в рабочее состояние и поддерживать её безупречную работу в течение определённого времени. Однако, если система прекращает работу корректно или пользователь хочет получить доступ к настройкам, они не могут повторить первоначальные действия из-за изменившегося контекста и отсутствия необходимой информации (утерян пароль, отсутствуют инструкции или просто сложный в управлении интерфейс, который изначально настраивался методом проб и ошибок). Информационный архитектор Йонас Сёдерстрём назвал это явление одноразовостью^[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, программы, на которой работают такие вики, как Википедия, а затем никогда не устанавливает никаких обновлений. Со временем веб-хостинг, скорее всего, обновит свои версии языков программирования (таких как PHP) и базы дааных (такой как MariaDB) без согласования с вебмастером. Через достаточно продолжительное время это, в конечном итоге, приведёт к сбоям в работе сложных веб-сайтов, которые не обновлялись, поскольку последние версии PHP и MariaDB будут содержать критические изменения, жёстко делая неработоспособными некоторые встроенные функции, ломая обратную совместимость и вызывая критические исключения^[англ.]. Другие проблемы, которые могут возникнуть с необновлённым программным обеспечением веб-сайта, включают уязвимости безопасности и спам.

Перепроектирование кода (Refactoring)

Основная статья: Рефакторинг

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

Программная энтропия

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

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

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

См. также

• Код с запашком – Характеристика исходного кода, намекающая на проблему качества
• Ад зависимостей – Программное обеспечение с кучей конфликтующих зависимостей
• Раздутое программное обеспечение – Ситуация с деградацией производительности программного обеспечения
• Хрупкость программного обеспечения^?! – Описывает, насколько трудно модифицировать программного обеспечения
• SOLID – Принципы разработки объектно-ориентированного программирования