Il marciume del software si riferisce principalmente alle prestazioni o al codice disordinato?

La definizione di marciume del software di Wikipedia si concentra sulle prestazioni del software. Questo è un uso diverso da quello a cui sono abituato; Ci avevo pensato molto di più in termini di pulizia e design del codice, in termini del fatto che il codice avesse tutte le caratteristiche di qualità standard: leggibilità, manutenibilità, ecc. Ora, è probabile che le prestazioni diminuiscano quando il codice diventa illeggibile, perché nessuno sa cosa sta succedendo. Ma il termine software rot ha un riferimento speciale alle prestazioni? o ho ragione nel pensare che si riferisca alla pulizia del codice? o è forse questo il caso di molteplici sensi del termine in uso comune - dal punto di vista dell'utente, ha a che fare con le prestazioni; ma per l'artigiano del software, ha più a che fare con la lettura del codice?

Il termine non è correlato alle prestazioni, almeno non ovunque lo abbia visto usato.

Si tratta in particolare di codice che non viene mantenuto bene e diventa ... sporco ... marcio. Si tratta di codice il cui design non è stato aggiornato in seguito alle modifiche ed è difficile da leggere e comprendere.

Affrontiamolo. "Software rot" non è un concetto tecnico ben definito. È più una descrizione peggiorativa di ciò che accade quando il software è gestito male.

La pagina di Wikipedia rappresenta una vista, ma ci sono viste chiaramente alternative. E potresti dire che le diverse opinioni riflettono le diverse priorità e preoccupazioni della persona che detiene le opinioni:

• Qualcuno che si concentra sulla velocità del software sarà più propenso a cercare prove di "marciume del software" nelle prestazioni.

• Qualcuno che si concentra sul design / architettura (ad esempio perché hanno bisogno di aggiungere nuove funzionalità o correggere bug di funzionalità), vedrà "marciume del software" da quella prospettiva.

E non è davvero utile dire la cui prospettiva è più giusta. (È un po 'come discutere se il turchese è più verde o più blu.)

Direi che il termine "marciume software" si riferisce generalmente all'idoneità per il compito da svolgere. Il software potrebbe diventare meno adatto per il compito previsto a causa dello strato su strato di correzioni di bug, nuove funzionalità e piccole modifiche. Nel loro insieme, questi possono influenzare negativamente sia la manutenibilità che le prestazioni. Inoltre, le esigenze dell'organizzazione cambieranno probabilmente nel tempo e il software potrebbe essere costretto a ruoli per i quali non è mai stato progettato. Tutti questi fattori fanno sì che il software diventi meno adatto alle esigenze dell'organizzazione e ciò può accadere anche con uno sforzo concertato per mantenere il software.

Wikipedia afferma che il marciume del software e il marciume del codice sono gli stessi. Non sono d'accordo.

La putrefazione del codice è la graduale perdita di leggibilità e manutenibilità man mano che vengono apportate sempre più modifiche al codice.

Il marciume del software è la graduale perdita di prestazioni quando il software viene spostato da un emulatore di ambiente a un altro. Un esempio è tutto il software Data General PDP in esecuzione su emulatori. In realtà, è l'ambiente che sta marcendo, non il software.

Il software in realtà non va male, diventa stantio, logoro o "marcisce" nel senso tradizionale.

Se l'ambiente in cui opera il software non cambia, il software durerà essenzialmente per sempre. Questo è il motivo per cui mi arrabbio così tanto quando qualcuno mi chiede se una libreria è "morta" perché l'autore non ha effettuato un aggiornamento ad essa negli ultimi 5 minuti (esagerando solo leggermente per effetto).

Ma l'ambiente di solito fa il cambiamento; i sistemi operativi sono patchati e aggiornati, i computer vengono sostituiti con altri più potenti e vengono installati nuovi programmi (come l'ultima versione di un client come Internet Explorer, driver di dispositivo o altre librerie), da cui il software può dipendere. Pertanto, il software deve essere aggiornato per tenere conto di tali modifiche.

Esistono sistemi software che funzionano ininterrottamente e in modo affidabile da decenni, senza essere significativamente aggiornati o mantenuti. Mi viene in mente il software COBOL in esecuzione su mainframe che gestiscono le transazioni bancarie (anche se tutti hanno dovuto essere modificati nel 1999 per gestire Y2K).

L'enfasi di Wikipedia sulla performance sembra mancare il punto; molte applicazioni software ottengono effettivamente un aumento delle prestazioni quando vengono installate in un ambiente più recente. L'articolo di Wikipedia sembra in realtà più interessato al gonfiamento del software .

"Marciume del software" - è un termine molto vago e può significare varietà di cose per chiunque, a seconda di come è la tua percezione del concetto, così come qual è il tuo punto di vista .

La definizione di Wikipedia sul marciume del software non stabilisce uno standard in quanto è anche scritta da alcuni individui. Penso che questo termine abbia una varietà di significati e debba essere suddiviso in aree specifiche, dove è referenziato.

• I programmatori possono comprenderlo come una base di codice non gestibile con pieno di anti-pattern, senza coerenza nello stile di denominazione e codifica.
• Gli amministratori di sistema possono capirlo come una cattiva prestazione, piena di perdite di memoria e inferno. Manutenzione.
• L'utente finale può capirlo come un software molto complicato, non intuitivo e difficile da lavorare.

Ho sempre pensato al marciume del software come una condizione che si verifica quando non si utilizza il software per un periodo di tempo. In qualche modo, il software si trasforma in uno stato in cui non è modificabile. Quindi quando lo si arriva a un punto in cui è possibile crearlo, non funziona con gli input e gli output come in precedenza. È quasi come se il codice si degradasse effettivamente nella forma anche se è archiviato in modo digitale.