Gnicie oprogramowania

Gnicie oprogramowania, znane również jako gnicie kodu, gnicie bitów, erozja oprogramowania, rozpad oprogramowania lub entropia oprogramowania – powolne pogorszenie wydajności oprogramowania wraz z upływem czasu lub wydłużanie jego czasu reakcji, co w końcu doprowadza do zwiększenia wadliwości oprogramowania, braku użyteczności i konieczności aktualizacji. Nie jest to zjawisko fizyczne: oprogramowanie faktycznie nie doznaje „rozpadu”, a raczej cierpi na brak elastyczności i brak aktualizacji z uwzględnieniem zmian środowiska, w którym przebywa.

Słownik jargon file, zbiór wiedzy hakerów, określa „gnicie bitów” jako żartobliwe wyjaśnienie degradacji oprogramowania wraz z upływem czasu, nawet jeśli „nic się nie zmieniło”; idea tego zjawiska jest prawie analogiczna do sytuacji, w której bity tworzące program doznawały rozpadu radioaktywnego.

Przyczyny

Kilka czynników jest odpowiedzialnych za gnicie oprogramowania, w tym zmiany w środowisku, w którym działa ten program, degradacja zgodności między częściami samego oprogramowania i ujawnianie się błędów w rzadko używanym (lub nieużywanym wcale) kodzie.

Zmiana środowiska

Kiedy zachodzą zmiany w środowisku programu, w szczególności zmiany, których nie przewidzieli projektanci systemu, oprogramowanie to może nie działać tak, jak pierwotnie zakładano. Na przykład, w wielu starszych grach komputerowych projektanci wykorzystywali taktowanie procesora jako zegar w grze, ale zegary nowszych procesorów były szybsze, więc prędkość działania gry odpowiednio wzrastała, przez co gra była coraz mniej użyteczna wraz z biegiem czasu.

Jednorazowość

Istnieją zmiany w środowisku nie powiązane z twórcami oprogramowania lecz z jego użytkownikami. Początkowo, użytkownik może uruchomić system, który będzie działał bezawaryjnie przez określony czas. Lecz w momencie gdy system przestaje działać poprawnie, lub też użytkownicy chcą uzyskać dostęp do konfiguracji, nie są w stanie powtórzyć pierwszego kroku ze względu na inny kontekst sytuacji i brak dostępu do informacji (np. utrata hasła, brak instrukcji, lub po prostu trudny do zarządzania interfejs użytkownika, który został najpierw skonfigurowany metodą prób i błędów). Architekt Informacji Jonas Söderström nazwał tę koncepcję jednorazowością, i określa ją jako „cechę systemu, która nie pozwala użytkownikowi na przywrócenie systemu po wystąpieniu awarii”.

Nieużywany kod

Rzadko używane obszary kodu, takie jak filtrowanie dokumentów lub interfejsy przeznaczone dla innych programów, mogą zawierać błędy, które nie zostały zauważone. Ze zmianami wymagań użytkowników i innych czynników zewnętrznych, kod ten może być wykonany później, ujawniając tym samym błędy i czyniąc program mniej funkcjonalnym.

Rzadko aktualizowany kod

Normalna obsługa oprogramowania i systemów oprogramowania również może powodować ich gnicie. W szczególności, jeśli program zawiera kilka elementów które są niezależne i mają równe prawa (z ang. „arm’s length principle”), nieuwzględnienie sposobu w jaki zmiany jednej części programu wpływają na inne może powodować powstanie błędów.

W niektórych przypadkach błąd może wystąpic w bibliotekach używanych przez program, których ewentualne modyfikacje negatywnie wpływają na zależne od nich oprogramowanie. Jeśli stara wersja biblioteki, która wcześniej pracowała z oprogramowaniem nie może być stosowana z powodu konfliktów z innym oprogramowaniem lub luk bezpieczeństwa, które zostały znalezione w starej wersji, może zabraknąć odpowiedniej wersji wymaganej biblioteki do użycia programu.

Klasyfikacja

Gnicie oprogramowania jest zazwyczaj klasyfikowane jako śpiące gnicie lub aktywne gnicie.

Śpiące gnicie

Oprogramowanie, które obecnie nie jest używane stopniowo staje się bezużyteczne, podczas gdy pozostałe fragmenty aplikacji się zmieniają. Zmiany w wymaganiach użytkowników i środowisku także przyczyniają się do pogorszenia stanu programu.

Aktywne gnicie

Oprogramowanie, które jest w sposób ciągły zmieniane może stracić swoją integralność z biegiem czasu, jeżeli właściwe procesy zapobiegawcze nie będą stosowane regularnie. Jednak wiele programów wymaga ciągłych zmian aby spełnić nowe wymagania i naprawić błędy, a przebudowa oprogramowania przy każdej zmianie rzadko okazuje się być praktyczna. Tym samym dochodzi w istocie do procesu ewolucji programu, powodując odbieganie od wstępnego projektu. W konsekwencji tego i zmieniających się warunków, założenia projektantów mogą być unieważnione, gdyż doprowadzą do powstania błędów.

W praktyce, dodawanie nowych funkcji może mieć wyższy priorytet niż aktualizacja dokumentacji; jednak bez dokumentacji, istnieje ryzyko utracenia określonej wiedzy dotyczącej pewnych części programu. W pewnym stopniu może to być złagodzone poprzez stosowanie tzw. najlepszych bieżących praktyk w odniesieniu do dokumentacji wewnętrznej i nazw zmiennych.

Aktywne gnicie oprogramowania zwalnia, jak tylko 'komercyjne życie' programu dobiega końca i dalszy jego rozwój ustaje. Użytkownicy często znajdują sposoby na obejście wszystkich pozostałych błędów, a zachowanie programu stabilizuje się, gdyż nie są w nim wprowadzane już żadne zmiany.

Przykład

Wiele przełomowych programów z pierwszych dni badań nad sztuczną inteligencją cierpi na nieodwracalne gnicie oprogramowania. Na przykład, oryginalna wersja programu SHRDLU (wczesny program do przetwarzania języka naturalnego) nie może być uruchomiona na żadnym nowoczesnym komputerze lub emulatorze, gdyż została zaprojektowana w czasach, gdy LISP oraz PLANNER były wciąż w fazie rozwoju, tym samym wykorzystuje nieistniejące już niestandardowe makra i biblioteki programistyczne.

Przykładowo administrator tworzy forum z użyciem oprogramowania typu Open-source, a następnie wprowadza duże zmiany, dodając nowe funkcje i opcje. Proces ten wymaga dużej ilości modyfikacji istniejącego kodu i odejścia od pierwotnej funkcji tego oprogramowania.

Na tym etapie istnieje kilka sposobów na wystąpienie zjawiska gnicia oprogramowania:

• Administrator może przypadkowo wprowadzić zmiany, które są sprzeczne względem samych siebie lub względem oryginalnego oprogramowania, co może doprowadzić do błędnego działania forum lub jego nagłej awarii. To pozostawia administratora w bardzo trudnej sytuacji: ponieważ w znacznym stopniu program odbiegł od oryginalnego kodu źródłowego, wsparcie techniczne i pomoc w odbudowie forum będą trudne do uzyskania.
• w oryginalnym kodzie źródłowym forum może być wykryta luka w zabezpieczeniach, wymagająca poprawek bezpieczeństwa. Jednak, ponieważ administrator zmodyfikował kod w tak dużym stopniu, to aktualizacja nie może być bezpośrednio wprowadzona do kodu, wymuszając na administratorze aby skutecznie przepisał aktualizację na nowo.
• Administrator, który zmodyfikował kod może odejść ze swojego stanowiska, pozostawiając swojemu następcy skomplikowane i silnie zmienione forum, nie mające pełnej dokumentacji. Bez pełnego zrozumienia zmian, nowy administrator będzie miał trudności w dokonywaniu dalszych modyfikacji bez powodowania konfliktów i błędów. (Ponadto, dokumentacja oryginalnego systemu może już być niedostępna; mogła być skasowana lub utracona w międzyczasie.)

Refaktoryzacja

Refaktoryzacja jest sposobem na rozwiązanie problemu z gniciem oprogramowania. Jest ona opisana jako proces przepisania istniejącego kodu w celu poprawy jego struktury, bez uszczerbku dla jego zewnętrznego zachowania. To obejmuje usuwanie martwego kodu i przepisanie tych fragmentów, które zostały mocno zmienione i tym samym nie działają już prawidłowo. Należy uważać, aby nie spowodować zmian w zewnętrznym zachowaniu programu, ponieważ może to prowadzić do braku kompatybilności i tym samym przyczyniać się do gnicia oprogramowania.

Zobacz też

• Piekło zależności
• Zapachy kodu
• Zasobożerność