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

[china]

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

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

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

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

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

 

[Ruslan M]

И как этого избежать и/или исправить?
Как диагностировать "гниль"?

 

[Urfin]

Извините, но не согласен с некоторыми тезисами:

Админ (Системные администраторы— сотрудники, в обязанности которых входит создание оптимальной работоспособности компьютеров и программного обеспечения для пользователей, часто связанных между собой общей работой на определённый результат.), установил движок форума с лицензией (MIT, BSD, LGPL, GNU GPL v2 и так далее, нужное подчеркнуть.*), изменил (модернизировал или добавил новые функции) согласно потребностям компании и пользователей форума (то есть в компании выполнял роль так же программиста и тестировщика).

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

Один из возможных выходов в данном случае (мнение) платить админу 3 ставки и нанять человека который документировал бы все изменения в коде и описывал ветки модернизации кода.

Со второй частью абсолютно согласен. Качество кода и его деградация это бич современной IT индустрии. По этому вопросу нужно смотреть в корень проблемы. Введение новых стандартов и эволюционирование алгоритмов и технологий обработки информации не может не привести к выпуску новых или изменённых библиотек ПО соответственно попадание их в систему вместе с обновлениями. А как быть с приложениями которые написаны на старых стандартах и библиотеках и какие планы выпуска обновлений для приложений. Например в скомпилированной программе OC WIN по объёму, код написанный программистом, по статистике занимает не более 5% от размера программы остальное библиотеки и заголовочные файлы (упрощённо). Соответственно и различия во времени выполнения программ и отказ в работе. Так что часть проблемы кроется в архитектуре ОС win. В *nix системах дела на много лучше так как архитектура обновлений и создание приложений значительно отличается. Например система портов в BSD системах или пакеты со своим набором библиотек типа snap (Snap-пакет— это пакет, который помимо готовой сборки самого приложения, включает в себя все необходимые зависимости и может работать (почти) в любом дистрибутиве Linux.) flatpak и т.д.