Software rovente. O almeno per età. Le metodologie di sviluppo del software possono rallentare questo processo, ma alla fine quasi tutti i sistemi software diventano così difficili da sostenere che una reimplementazione è inevitabile.
Ma qual è quella cosa che peggiora con il tempo chiamato? Integrità? Coesione? Entropy? L'ammontare del debito tecnico? C'è un nome concordato per il peggioramento di quella proprietà che causa tali cambiamenti nella manutenibilità?
Alcuni software di grandi dimensioni stanno marcendo abbastanza lentamente, perché una parte significativa di essi viene ridisegnata / reimplementata / refactored di volta in volta.
Prendi ad esempio il compilatore GCC . Ha 28 anni, ha più di 13 milioni di righe di codice sorgente (e misurare le sue dimensioni è impegnativo, a seconda degli strumenti che utilizzi potresti avere una dimensione di 20MLOC) ed è ancora vivo. Non so quali parti di esso siano più vecchie di 10 anni, ma certamente alcune di esse sono (ad esempio il suo garbage collector, o il suo pass manager, o la idea di Generic & Gimple rappresentazioni, anche se ovviamente si sono evolute in modo significativo e recente).
Allo stesso modo per il kernel di Linux. Ha 24 anni. E probabilmente per Firefox .
E non c'è un momento in cui si possa dire che GCC o il kernel Linux sono stati interamente reimplementati.
La mia ipotesi è che qualsiasi software di grandi dimensioni (ad esempio oltre dieci milioni di righe di codice, anche se tutti sappiamo che si tratta di una metrica scadente) non viene mai reimplementato. O ottiene sostituito (da qualche nuovo software con una specifica diversa) o viene comunque mantenuto continuamente, o semplicemente scompare perché a nessuno importa. .. (forse è successo a strani sistemi operativi su computer bizzarri come Norsk Data 500 - che ho usato durante i miei studi a ENS Cachan intorno al 1983)
I indovina che i sistemi operativi mainframe IBM (da OS / 360 a z / OS ) ne è un esempio. Sui rari mainframe di oggi, è possibile che alcuni codici legacy in essi siano più di 40 anni. Ma, naturalmente, molti server utilizzano Linux oggi, ma non si può dire che Linux sia una reimplementazione di OS / 360.
Il motivo è probabilmente economico; Immagino sia difficile convincere la capitale a riscrivere tali mostri da zero. E anche perché riscrivere tali mostri richiederebbe anni (e non hai la garanzia che il risultato sarebbe migliore). Leggi il mese Mese del libro
di Brook di Brook.Ora, sicuramente, per un lungo periodo di tempo, ogni software svanirà. Credo che in 100 anni, Linux o GCC (e persino C o C ++ o POSIX) potrebbero essere dimenticati ... Ma sarò già morto da tempo.
Ma suppongo che debito tecnico sia la parola che descrive meglio ciò che stai pensando circa.
Penso che riguardi il software adatto al suo ambiente e alle aspettative dello sviluppatore.
Che cosa intendo per ambiente: il software che non si evolve funziona con formati e protocolli di file che gradualmente passano di moda. Il sistema operativo può essere sostituito rendendo le parti del codice base dispari almeno anche se in qualche modo continuano a funzionare. I vecchi programmi non conoscono Internet e mancano molte opportunità lì.
Cosa intendo per aspettative: il linguaggio di programmazione del software cambia lentamente le espressioni idiomatiche e alla fine viene fuori moda. La metodologia del software si evolve e anche vent'anni fa era accettabile scrivere codice senza test, è almeno sospetto al momento. Quindi la qualità percepita della base di codice di vent'anni è molto più bassa agli occhi del programmatore di oggi dato che non può lavorare con esso in un modo che lei si aspetta.
Non penso che ci sia una proprietà magica che renderebbe il programma ben mantenuto libero nel tempo. Il problema principale è che quasi nessuno capisce che "manutenzione" non significa solo "risolvere problemi ovvi", ma anche "allineare continuamente il codice con il mondo che cambia". Quando si risolvono problemi evidenti, si finisce con il software pieno di comportamenti "oh, questo è spento" che nessuno vuole usare o sviluppare. E poi dirai che il codice è marcio.
Leggi altre domande sui tag maintainability