"Tutto il software ha una data di scadenza entro la quale deve essere riscritto da zero." [chiuso]

Ecco un'influente opinione del programmatore sull'argomento: "il singolo errore strategico peggiore che qualsiasi azienda di software può fare: hanno deciso di riscrivere il codice da zero." [1 ] - Joel Spolsky

Considera quante cose possono cambiare in tempi brevi: appaiono nuovi sistemi operativi. I sistemi operativi esistenti vengono ricostruiti. Pacchetti di terze parti compaiono, sviluppano, abbandonano il supporto o diventano obsoleti. Viene visualizzato un nuovo hardware, inclusi dispositivi e paradigmi completamente nuovi (ad esempio touch-screen che diventano la norma).
I paradigmi esistenti sono esposti come difetti sfruttabili e vengono abbandonati, o semplicemente svaniscono dal mercato. Tutti questi richiedono che la tua applicazione cambi, e nessuno è dovuto all'incompetenza dei tuoi senior.

Non sarei d'accordo sul fatto che il software always debba essere riscritto da zero, ma l'unica (e superiore) alternativa alle riscritture è il normale refactoring in corso. L'idea che tu possa scrivere un'intera applicazione e sia fatta per sempre è semplicemente sbagliata.

Lavoravo per un'azienda che aveva il codice sorgente che aveva "copyright 1984" nella parte superiore del file. Era ancora nel codebase perché funzionava, e non era stato rimosso o sostituito perché funzionava ancora .

Ci sono molte cose che possono essere riscritte alla fine, ma è così raro che potrebbe anche non esserlo mai. per esempio. TCP / IP è ancora con noi anche se stiamo tentando di ottenere la riscrittura di IP implementata. HTTP è ancora qui anche se è stato leggermente refactored in HTTP 1.1, è ancora più o meno lo stesso di sempre. Ci sono molti altri esempi.

La riscrittura di tutto il pubblico non sa come progettare il software al primo tentativo.

“All software has an expiration date by which time it must be rewritten from scratch.”

Questo è vero solo per software progettato e implementato in modo improprio. Per software correttamente progettato è vero che:

"All sofware is completely replaced every so often."

Ma questo è lo stesso di "Le cellule nel corpo umano sono completamente sostituite ogni 7-10 anni". Ciò non significa che la persona rinasce completamente dopo che il periodo di tempo trascorre, ma i frammenti vengono continuamente sostituiti, quindi non ci sono cellule più vecchie di 10 anni. Il software correttamente progettato dovrebbe avere la stessa proprietà. Soprattutto se è un sistema complesso e grande. Quando piattaforme, framework e linguaggi cambiano, diventa molto più costoso sviluppare per i precedenti. Ma sostituire l'intero sistema in un'unica grande riscrittura è una pessima idea, proprio come dice Joel Spolsky. Invece, riscrivere pezzi troppo costosi da mantenere è un'idea molto più realistica. Quindi, nel corso di pochi anni, è possibile sostituire praticamente tutto il codebase riducendo al minimo l'impatto di non avere software funzionante per un periodo di tempo prolungato.

Dipende dal codice, da ciò che fa e da chi lo ha scritto.

La risposta giusta , naturalmente, è progettare e implementare il software in modo tale da poter essere facilmente aggiornato senza dover essere completamente scartato e riscritto ogni pochi anni. Fattore aggressivo, distribuire in modo incrementale, test test test e pensare al futuro.

Ma ...

Alcuni data center sono ancora in esecuzione su hardware e software vintage anni '80 perché il rischio di passare a una nuova piattaforma è irragionevolmente alto; si tratta di sistemi di elaborazione delle transazioni online ad alto volume, come una banca d'investimento o un sistema di gestione degli ordini per una coporation multimilionaria, in cui i tempi di fermo sono misurati in milioni di dollari al minuto. Qualsiasi passaggio ad una nuova piattaforma ¹ dovrebbe essere effettivamente istantaneo (meno di pochi minuti di inattività), e il nuovo sistema dovrebbe eseguire almeno e affidabile come il sistema esistente; dal punto di vista dell'utente finale, la transizione dovrebbe essere invisibile.

Questo codice non verrà scartato in qualsiasi momento presto. Laddove possibile, le migrazioni vengono eseguite in modo frammentario, ma molti di questi sistemi sono app COBOL monolitiche e non facilmente refactoring; semplicemente non era una considerazione allora.

Non riesco a immaginare la progettazione di un sistema che dovrebbe essere scartato, ridisegnato e riscritto dopo solo 2-3 anni, ma non voglio nemmeno fare una dichiarazione generale che non è una possibilità. Poiché ci sono molti domini applicativi nello sviluppo del software, tutti con esigenze e pratiche diverse che sono necessarie per mantenere un'azienda competitiva. Suppongo che quelle aziende in cui il "time to market" sia della massima importanza rientrerebbero in quella categoria. Sfortunatamente, scommetto che il 99% delle aziende che sostengono tale richiesta, in realtà non sono così "time to market" tanto importanti quanto credono di esserlo. Un'applicazione più robusta pochi mesi dopo probabilmente servirebbe i loro interessi molto meglio, ma poi costruire applicazioni solide richiede abilità e pazienza, quindi è più facile fare in modo che la coperta sostenga che il time-to-market è il motivo per cui non stiamo facendo bene.

Ad ogni modo, ho lavorato con un buon numero di sviluppatori "Senior" che mi sono piaciuti immensamente perché li ho fatti rifare il lavoro (a volte molte volte) che avrebbe portato a 2-3 anni più facile da scartare di sistema di correzione se lascio che il loro lavoro lo faccia nel prodotto. Quindi essere "Senior" non significa necessariamente che la persona sappia come sviluppare efficacemente il software.

Non credo che ci sia una risposta "giusta" alla tua domanda senza conoscere i dettagli sul dominio dell'applicazione in cui stai lavorando. I sistemi "ricostruiti" sono essenzialmente lo stesso sistema con miglioramenti o sono davvero nuove applicazioni? Se sono sostanzialmente uguali, i tuoi "senior" sono completamente sbagliati. Ovviamente mancano competenze in molti settori. D'altra parte, se la nuova applicazione è davvero una "nuova" applicazione che condivide solo tratti simili come l'applicazione precedente, allora forse i ragazzi "senior" stanno adottando l'approccio più efficiente.

Riscrivere da zero ogni 2-3 anni mi sembra estremo. Ma una ragione per cui si potrebbe decidere di riscrivere da zero è perché i requisiti del sistema attuale sono cambiati così tanto da non avere alcuna somiglianza con le specifiche originali. Ciò significa che l'architettura sottostante potrebbe non essere quella giusta per i requisiti correnti. Quindi, invece di un sistema ben progettato e codificato, si dispone di un sistema costituito da patch e modifiche al design straniere che hanno senso solo quando si guardano alla progressione dei requisiti fin dal primo giorno.