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

Software rot

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

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

Причины

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

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

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

Некроз

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

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

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

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

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

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

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

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

Спящая гниль

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

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

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

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

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

Примеры

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

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

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

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

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

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

Рефакторинг

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

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

Рекомендации

  1. ^ Раймонд, Эрик. "Бит гниль". Файл жаргона. Получено 3 марта 2013.
  2. ^ Inc, Зифф Дэвис (28 января 1992 г.). PC Mag. Ziff Davis, Inc. стр. 286.
  3. ^ Йонас Сёдерстрём. «Разложимость: следствие технологической гнили».
  4. ^ Фаулер, Мартин (11 октября 2007 г.). "Что такое рефакторинг". Получено 2007-11-22.