Программная гниль

редактировать

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

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

Содержание
  • 1 Причины
    • 1.1 Изменение окружающей среды
    • 1.2 Возможность однократного использования
    • 1.3 Неиспользуемый код
    • 1.4 Редко обновляемый код
  • 2 Классификация
    • 2.1 Бездействующая гниль
    • 2.2 Активная гниль
  • 3 Примеры
    • 3.1 Пример программы AI
    • 3.2 Пример онлайн-форума
  • 4 Рефакторинг
  • 5 См. также
  • 6 Ссылки
Причины

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

Изменение среды

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

Простота использования

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

Неиспользуемый код

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

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

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

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

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

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

Бездействующая гниль

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

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

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

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

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

Примеры

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

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

Пример онлайн-форума

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

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

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

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

См. Также
Ссылки
Последняя правка сделана 2021-06-08 08:28:03
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте