Esistono casi studio concreti sulla riscrittura delle percentuali di successo / fallimento del software?

Ho visto più post sulla riscrittura di applicazioni cattive, esperienze della gente al riguardo qui sui programmatori e un articolo che ho preparato di Joel Spolsky sull'argomento, ma nessuna prova concreta o case study. A parte i due esempi forniti da Joel e alcuni altri post qui, cosa fai con una base di codice sbagliata e come decidi cosa farne sulla base di studi reali?

Per il caso in questione, ci sono due client che conosco che hanno entrambi un vecchio codice legacy. Continuano a zoppicare perché, come uno di loro ha scoperto, una riscrittura era un disastro, era costoso e non funzionava davvero per migliorare molto il codice. Quel cliente ha una logica aziendale molto complicata, come hanno scoperto rapidamente i riscrittori.

In entrambi i casi, si tratta di applicazioni mission-critical che generano molti ricavi per l'azienda. Quello che ha tentato la riscrittura ha sentito che avrebbero colpito un muro di mattoni se il software legacy non fosse stato aggiornato ad un certo punto in futuro. Per me, quel tipo di rischio merita ricerca e analisi per garantire un percorso di successo.

Ci sono stati casi studio reali che hanno studiato questo? Non vorrei tentare una grande riscrittura senza conoscere alcune buone pratiche, insidie ​​e successi basati su studi reali.

Dopo: okay, dopo ulteriori ricerche, ho trovato tre articoli interessanti su casi studio:

1. Riscrivi o Riutilizza . Hanno fatto uno studio su un'app Cobol che è stata convertita in Java.
2. L'altro riguardava il riutilizzo del software: esperienze e percezioni degli sviluppatori .
3. Riutilizzare o riscrivere Un altro studio sui costi di manutenzione rispetto a una riscrittura.

Di recente ho trovato un altro articolo sull'argomento: The Great Rewrite . Lì l'autore sembra colpire alcuni dei problemi principali. Insieme a questo è nata l'idea di prototipare usando il nuovo stack tecnologico proposto e misurando la velocità con cui gli sviluppatori lo hanno raccolto. Tutto questo era un preludio a una riscrittura, che pensavo fosse una grande idea!

Non posso prendermi il merito per questi grandi commenti, ma non sono mai stati inseriti in una risposta dall'autore originale, quindi lo segnerò come wiki della community.

Non conosco casi di studio, ma penso che la risposta standard per un approccio sia probabilmente "aggiungi test unitari e refactor".

Mi sembra probabilmente l'approccio più a rischio disponibile. Certo, non conosco abbastanza dettagli per essere certo che sia l'approccio giusto, ma in base a ciò che so finora, non conosco molto che sia particolarmente probabile che sia molto meglio.

Se eseguono test unitari (correttamente - catturano veramente tutti i requisiti) è difficile trovare un modo per il refactoring di provocare un vero disastro. Il peggio che può succedere è che non fai tutti i progressi che vuoi. Allo stesso tempo, se la loro base di codice è in cattive condizioni come suggerisce la domanda, è abbastanza probabile che saranno necessari sforzi seri per consentire il progresso, indipendentemente dal percorso intrapreso.

Suppongo che i progetti di riscrittura non siano significativamente diversi nelle percentuali di fallimento rispetto ai progetti in generale e fare riferimento all'ultimo rapporto CHAOS per le migliori informazioni.

Ho scremato lavorando in modo efficace con il codice legacy di Michael Feathers qualche tempo fa e ho scoperto che offriva alcune buone intuizioni sulla pratica del mondo reale di mantenere il codice legacy, incluso scrivere test (anche quando non sai a cosa servisse il codice) e di refactoring / riscrittura del corso. È un po 'datato ma molto apprezzato su Amazon.

Parlando per esperienza e vivendo in un'azienda che ha concepito male l'architettura aziendale sin dall'inizio, posso onestamente dire che il problema più grande è lo sviluppo di una comprensione globale.

L'idea che un sistema possa essere suddiviso in pezzi e compreso individualmente è errata. Ad un certo punto un singolo individuo, o più individui, dovevano essere in grado di concepire l'intero problema nella sua interezza. Se quel problema è una serie di problemi aziendali e le tecnologie che li guidano; potrebbero essere necessari diversi anni in un'azienda per comprendere tutti i sistemi a un livello in cui è possibile sostituirli senza un disastro o un requisito mancante. Questo è stato certamente il caso della mia azienda quando ho assunto l'incarico di direttore della tecnologia. Se non fosse per il fatto che io stesso sono un programmatore, non sarei stato in grado di comprendere lentamente tutti i dettagli dell'architettura mal organizzata, strettamente unita, strettamente legata e l'integrazione della tecnologia. Se sono piccoli dettagli nascosti e non documentati simili"We put the eBay order number in the "SYSOENT.PO_NUMBER" field in the ERP system because that's what Wendell the VB coder from Florida decided to do" vengono trascurati i risultati possono essere disastrosi e l'unico modo per saperlo è scoprire lentamente tutto.

Se a qualcuno viene chiesto di sostituire il motore su un aereo durante il volo o di affrontare una morte certa, data la quantità adeguata di strumenti e risorse di cui l'individuo avrebbe bisogno per sapere come sostituire i sensori, il sistema idraulico, come reinstradare il flusso di carburante , manipolare sistemi che non sono mai stati progettati per essere modificati o manipolati esternamente o dalla cabina di pilotaggio. Questo è spesso la prospettiva di riscrivere un'applicazione aziendale. L'applicazione è di solito martellata nel business tra molte altre tecnologie diverse.

Immagino che il mio punto principale sia che il sistema deve essere compreso quasi nella sua piena complessità, e deve essere compreso a un certo punto nel tempo nella sua completezza affinché il nuovo sistema sia correttamente "ingegnerizzato" e non solo "realizzato".

I cookie sono creati, il software (dovrebbe essere) progettato.

Ci sono molti esempi di compagnie morte per riscrittura, come Netscape . Ci sono anche aziende sopravvissute a una riscrittura senza grossi problemi come Twitter .

Non ci sono casi studio quantificati, perché non è possibile avere un esperimento di controllo in cui si guarda al successo aziendale di non riscrivere rispetto al successo aziendale di riscrittura. Ogni applicazione è diversa.

Ci sono alcuni casi ovvi in ​​cui una riscrittura ha senso e molti casi in cui non lo è. Ho preparato una piccola ricetta per capire se una riscrittura avrebbe senso nel tuo caso.

Penso che la riscrittura abbia più senso al giorno d'oggi perché stiamo programmando rapidamente sulle spalle di strutture invasive sempre migliori come Rails, Grails, AngularJS. Se vuoi passare da js semplici a Angular, una riscrittura è tutto ciò che puoi fare. Potrebbe ancora avere molto senso. Se stai sostituendo un'implementazione fai-da-te con un'altra (come tutti gli esempi nell'articolo di Joel Spolsky ), probabilmente sei pazzo.

Non troverai molti case study non distorti che non siano altro che dopo i rapporti di azione - la maggior parte delle persone non pagherà per avere lo stesso lavoro svolto almeno due volte (una volta come riscrittura, una volta come aggiornamento, il migliore il caso consisterebbe in più riscritture / aggiornamenti da diversi team).

Il caso di studio che hai scoperto sembra essere stato prodotto da Fujitsu e, ovviamente, il risultato è stato che era meglio usare gli strumenti di Fujitsu.

Da un punto di vista organizzativo, una riscrittura è chiaramente un errore solo quando l'applicazione riscritta non funziona o il progetto viene annullato prima che sia terminato, altrimenti è impossibile sapere se il ritardo nel rilascio della versione riscritta è stato il causa della perdita subita o semplicemente casuale. Se cancellato prima del termine, viene generalmente considerato uno spreco totale di tempo e risorse. Un aggiornamento può potenzialmente avere lo stesso problema, ma è improbabile che essere incrementali si trovi sulla stessa scala (ottieni qualcosa per i tuoi soldi).

Il miglior caso dal punto di vista della programmazione è fare entrambe le cose: aggiornamenti incrementali durante la riscrittura, supportandosi e ispirandosi a vicenda. A meno che tu non abbia squadre diverse, ciò richiederà naturalmente più tempo.

Nota che questo fornisce una linea guida approssimativa per quando dovresti considerare una riscrittura totale - il progetto è abbastanza piccolo da poterlo fare così facilmente, o l'organizzazione è abbastanza grande da permettersi di fare entrambi, contando lo sforzo o il costo di apprendimento vale la pena. Si noti inoltre che se la riscrittura non raggiunge mai la rilavorazione, ciò può significare diverse cose, ma tutto il resto è uguale, probabilmente significa che una riscrittura non era necessaria.