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

Материал из wikixw
Перейти к навигации Перейти к поиску

Не путать с Деградация данных.

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

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

JOSM

Причины[править]

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

Изменение среды[править]

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

Onceability[править]

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

Неиспользуемый код[править]

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

Редко обновляемый код[править]

См. также: Ад зависимости

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

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

Подключение к Интернету[править]

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

Классификация[править]

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

Спящая гниль[править]

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

Активный rot[править]

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

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

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

Примеры[править]

Пример программы ИИ[править]

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

Пример форума[править]

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

Отсюда, есть несколько способов Software Rot может повлиять на систему:

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

Рефакторинг[править]

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

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

См. также[править]

Пруф[править]

//ru.knowledgr.com/01067048?ysclid=l3hgxw7699