Rotace softwaru - Software rot

Rotace softwaru , známá také jako bitová hniloba , rotace kódu , softwarová eroze , rozpad softwaru nebo softwarová entropie, je buď pomalé zhoršování kvality softwaru v průběhu času, nebo jeho klesající odezva, která nakonec povede k tomu, že se software stane vadným, nepoužitelným nebo bude potřebovat upgradovat . Nejedná se o fyzický jev: software se ve skutečnosti nerozkládá, ale spíše trpí nedostatkem reakce a aktualizace s ohledem na měnící se prostředí, ve kterém sídlí.

Soubor Jargon , kompendium hackerské tradice, definuje „bit rot“ jako vtipné vysvětlení degradace softwarového programu v průběhu času, i když „se nic nezměnilo“; myšlenka je téměř jako by kousky, které tvoří program, podléhaly radioaktivnímu rozpadu.

Příčiny

Za rotací softwaru je zodpovědných několik faktorů, včetně změn prostředí, ve kterém software funguje, degradace kompatibility mezi částmi samotného softwaru a výskyt chyb v nepoužívaném nebo zřídka používaném kódu.

Změna prostředí

Dojde -li v prostředí programu ke změnám, zejména ke změnám, se kterými návrhář programu nepočítal, software již nemusí fungovat tak, jak bylo původně zamýšleno. Například mnoho raných designérů počítačových her používalo ve svých hrách rychlost hodin CPU jako časovač . Novější hodiny CPU však byly rychlejší, takže se podle toho zvýšila i rychlost hraní, takže hry byly časem méně použitelné.

Nezrušitelnost

Existují změny v prostředí, které nesouvisejí s návrhářem programu, ale s jeho uživateli. Zpočátku mohl uživatel uvést systém do provozuschopného stavu a nechat jej po určitou dobu fungovat bezchybně. Když ale systém přestane fungovat správně nebo uživatelé chtějí získat přístup k ovládacím prvkům konfigurace, nemohou tento počáteční krok zopakovat kvůli odlišnému kontextu a nedostupným informacím (ztracené heslo, chybějící pokyny nebo jednoduše těžko spravovatelný uživatel) rozhraní, které bylo poprvé konfigurováno metodou pokusu a omylu). Informační architekt Jonas Söderström pojmenoval tento koncept jako Onceability a definuje jej jako „kvalitu technického systému, který brání uživateli v obnovení systému, jakmile selže“.

Nepoužitý kód

Zřídka používané části kódu, jako jsou filtry dokumentů nebo rozhraní navržené pro použití jinými programy, mohou obsahovat chyby, které zůstanou bez povšimnutí. Se změnami požadavků uživatelů a dalšími externími faktory může být tento kód spuštěn později, čímž se odhalí chyby a software bude vypadat méně funkční.

Zřídka aktualizovaný kód

Běžná údržba softwaru a systémů může také způsobit hnilobu softwaru. Zejména, když program obsahuje více částí, které fungují na vzdálenost jedné ruky od druhé, když nezohledníme, jak změny jedné části ovlivní ostatní, mohou způsobit chyby.

V některých případech to může mít podobu knihoven, které software používá, které jsou měněny způsobem, který nepříznivě ovlivňuje software. Pokud starou verzi knihovny, která dříve pracovala se softwarem, již nelze použít kvůli konfliktům s jiným softwarem nebo chybám zabezpečení, které byly nalezeny ve staré verzi, nemusí již existovat životaschopná verze potřebné knihovny pro program použít.

Klasifikace

Softwarová hniloba je obvykle klasifikována jako spící hniloba nebo aktivní hniloba .

Spící hniloba

Software, který není aktuálně používán, se postupně stává nepoužitelným, protože se mění zbytek aplikace. Ke zhoršení stavu přispívají také změny požadavků uživatelů a softwarového prostředí.

Aktivní hniloba

Software, který je průběžně upravován, může v průběhu času ztratit svou integritu, pokud nejsou důsledně uplatňovány správné procesy snižující závažnost. Mnoho softwaru však vyžaduje neustálé změny, aby splňovalo nové požadavky a opravovalo chyby, a přepracovat software pokaždé, když dojde ke změně, je jen zřídka praktické. To vytváří v podstatě evoluční proces programu, což způsobuje, že se odchýlí od původního navrženého designu. V důsledku toho a měnícího se prostředí mohou být předpoklady učiněné původními návrháři zneplatněny, což zavádí chyby.

V praxi může být přidávání nových funkcí upřednostňováno před aktualizací dokumentace ; bez dokumentace je však možné, že dojde ke ztrátě konkrétních znalostí týkajících se částí programu. Do určité míry to lze zmírnit dodržováním nejlepších současných postupů pro konvence kódování .

Aktivní softwarová hniloba se zpomalí, jakmile se aplikace blíží ke konci své komerční životnosti a další vývoj skončí. Uživatelé se často učí obejít všechny zbývající softwarové chyby a chování softwaru se stává konzistentním, protože se nic nemění.

Příklady

Příklad programu AI

Mnoho klíčových programů z počátků výzkumu AI trpělo nenapravitelnou hnilobou softwaru. Například původní program SHRDLU (raný program pro porozumění přirozenému jazyku) nelze spustit na žádném moderním počítači nebo počítačovém simulátoru, protože byl vyvinut v dobách, kdy byly LISP a PLANNER ještě ve stádiu vývoje, a proto používá nestandardní makra a softwarové knihovny, které již neexistují.

Online fórum příklad

Předpokládejme, že správce vytvoří fórum pomocí softwaru fóra s otevřeným zdrojovým kódem a poté jej výrazně upraví přidáním nových funkcí a možností. Tento proces vyžaduje rozsáhlé úpravy stávajícího kódu a odchylku od původní funkce tohoto softwaru.

Odtud existuje několik způsobů, jak může rotace softwaru ovlivnit systém:

  • Správce může omylem provést změny, které jsou v konfliktu mezi sebou nebo původním softwarem, což způsobí, že se fórum bude chovat neočekávaně nebo se úplně rozpadne. Tím se dostávají do velmi špatné situace: jelikož se tak výrazně odchýlili od původního kódu, bude obtížné získat technickou podporu a pomoc při obnově fóra.
  • Ve zdrojovém kódu původního fóra může být objevena bezpečnostní díra vyžadující bezpečnostní opravu. Protože však administrátor kód tak rozsáhle upravil, oprava nemusí být přímo použitelná pro jejich kód, což vyžaduje, aby administrátor aktualizaci skutečně přepsal.
  • Správce, který provedl změny, mohl uvolnit své místo a ponechat novému správci spletité a silně upravené fórum, kterému chybí úplná dokumentace. Bez úplného pochopení úprav je pro nového správce obtížné provádět změny bez zavádění konfliktů a chyb. Navíc dokumentace původního systému již nemusí být k dispozici, nebo ještě hůře, zavádějící kvůli jemným rozdílům ve funkčních požadavcích.

Refaktorování

Refaktoring je prostředek k řešení problému hniloby softwaru. Je popisován jako proces přepisování stávajícího kódu za účelem vylepšení jeho struktury bez ovlivnění jeho vnějšího chování. To zahrnuje odstranění mrtvého kódu a přepsání částí, které byly rozsáhle upraveny a již nefungují efektivně. Je třeba dbát na to, aby se nezměnilo vnější chování softwaru, protože by to mohlo způsobit nekompatibilitu a tím samo o sobě přispět k hnilobě softwaru.

Viz také

Reference