Sei mai stato coinvolto in una GRANDE riscrittura? [chiuso]

Joel Spolsky ha detto in uno dei suoi famosi post:

L'unico peggior errore strategico che qualsiasi azienda di software può fare: riscrivere il codice da zero.

Chad Fowler ha scritto:

Hai visto i video, i post del weblog e l'hype e hai deciso di implementare nuovamente il tuo prodotto in Rails (o Java, .NET, Erlang, ecc.).

Attenzione. Questo è un percorso più lungo, più difficile, più soggetto a guasti di quanto ti aspetti.

Sei mai stato coinvolto in una GRANDE riscrittura?
Sono interessato alla tua esperienza su questo tragico argomento e, in particolare, a qualsiasi grande riscrittura che è stata completata con successo (se presente).

Sono stato coinvolto in alcune riscritture durante la mia carriera ed erano tutti disastri. Penso che falliscano tutti per gli stessi motivi

• È necessaria una notevole sottovalutazione dello sforzo: ogni volta che qualcuno desidera una riscrittura, è perché il vecchio sistema utilizza la vecchia tecnologia e difficile da mantenere. Quello che non riescono a considerare è che, a causa della sua età, può avere 30-40 anni-uomo di sforzi di sviluppo. Pensare di poter riscrivere il tutto in 6 mesi con una squadra di 5 è sciocco.
• Conoscenza perduta: il vecchio sistema esiste da così tanto tempo, fa un sacco di cose ed è agganciato a tutto. Non esiste una documentazione aggiornata e nessun singolo punto di autorità che sappia effettivamente tutto ciò che fa il sistema. Ci saranno conoscenze con utenti particolari in particolari dipartimenti e trovarli tutti è difficile o impossibile.
• Decisioni di cattiva gestione: le riscritture in cui sono stato coinvolto avevano aspettative simili da parte della direzione: il nuovo sistema dovrebbe essere "fatto" e il vecchio sistema potrebbe semplicemente essere spento in una data, un periodo particolare. Nessuna altra opzione era accettabile. Penso che abbiano questo in testa, perché stanno spendendo tutti questi soldi per assumere nuove persone per questo enorme progetto. In realtà, la migliore strategia di mitigazione del rischio è quella di riscrivere le principali funzioni del vecchio sistema, dire affrontare il 50-75% del vecchio sistema per una prima versione, e poi vedere come funziona! A causa del n. 1 e n. 2 sopra, questo probabilmente funzionerebbe molto meglio, poiché scopriamo alcune delle funzionalità che mancavano e ciò che è necessario per spegnere effettivamente il vecchio sistema.

Le riscritture possono avere molto successo se le si esegue correttamente. Non so se questi soddisfano la tua soglia di progetti "BIG" (TM), ma lascia che ti descriva un paio di riscritture di maggior successo.

Progetto 1

La società per cui lavoravo aveva un sistema di stampa a strisce per scaffali utilizzato per generare le etichette che vedi sugli scaffali dei negozi da qualcosa chiamato planogramma . Il planogramma è stato generato in software standard del settore e i nostri strumenti leggono quel documento per creare le strisce di scaffali utilizzando un modello per il negozio di destinazione. Il software di template era un casino con macchine a stati finiti nidificati che si estendevano su diverse classi e 3 DLL. Quando giunse il momento di implementare l'approccio (allora) in attesa di brevetto per realizzare le schede pegging, era chiaro che l'attuale codice non poteva supportare ciò che volevamo fare.

Soluzione: abbiamo eseguito l'ambito della riscrittura solo sul motore del modello. Abbiamo utilizzato una progettazione OO adeguata per soddisfare i requisiti attuali e soddisfare i nuovi requisiti della scheda di supporto. Il tempo per la riscrittura era di 1 mese. Se avessimo fatto una riscrittura su vasta scala dell'intera catena di utensili, ci sarebbe voluto molto più di un anno, ma non abbiamo avuto bisogno di farlo.

Progetto 2

Un'applicazione web creata dal nostro team da zero stava iniziando a diventare troppo grande per il suo design originale. Il nostro cliente aveva anche una serie di nuovi requisiti che avrebbero reso il sito molto migliore per i nostri utenti, più conforme "Web 2.0" se lo desideri. Mentre avremmo potuto trasformare il nostro progetto esistente in una struttura a cornicetta che avevamo attualmente, la manutenzione è stata un incubo. Conoscevamo intimamente l'applicazione e sapevamo quali parti dovevamo anticipare e quali parti sarebbero andate via come parte della nuova versione.

Soluzione: il nostro team ha impiegato 3 mesi per completare - non è stato banale. Il prodotto finale è stato più veloce, più scalabile e più piacevole per gli utenti finali. Abbiamo superato le aspettative dei nostri clienti. Detto questo, abbiamo dovuto dividere il nostro team in modo che le correzioni più immediate dei bug e le patch di aiuto alla banda venissero eseguite sul sistema esistente mentre l'altra metà lavorava sul nuovo sistema. Abbiamo effettuato test approfonditi e incorporato all'inizio del processo. Il motivo per cui ha funzionato così bene è perché conoscevamo intimamente questa applicazione e il nostro client.

Progetto 3

Devo includere un fallimento qui. Stavamo supportando un cliente che aveva bisogno di uno strumento di gestione delle informazioni da utilizzare in situazioni di catastrofe / crisi. Abbiamo ereditato un'applicazione Java Swing che gli sviluppatori originali hanno scritto senza capire veramente Swing. Con ciò intendo dire che non hanno seguito le raccomandazioni di Sun per gestire Swing e gestire correttamente l'interfaccia utente, di conseguenza si otterrebbero infiniti loop di eventi e altri problemi strani e difficili da tracciare. Di conseguenza era pieno di bug, problemi di interfaccia utente, ecc. Questa era un'applicazione molto complicata. Per preservare la nostra sanità mentale, abbiamo tentato di riscrivere l'app Swing mal scritta in un'app Swing ben scritta.

Soluzione: abbiamo completato la riscrittura in circa 4,5 mesi quando abbiamo stimato 3 mesi. L'applicazione ha funzionato meglio, sia nell'interfaccia utente che in quanti dati poteva gestire. Poi è successo lo tsunami nel 2004. La vastità del numero di persone che hanno dovuto tracciare ha dimostrato che Swing era la tecnologia sbagliata per ciò di cui avevano veramente bisogno. Non siamo riusciti a tenere il passo con la nostra messa a punto delle prestazioni e alla fine hanno abbandonato lo strumento a favore di un'app Web insieme creata dal team Oracle che avevano in casa. Certo, potremmo giustificare ciò che abbiamo fatto sulla base delle conoscenze che avevamo in quel momento, ma la riscrittura non era abbastanza aggressiva e non siamo riusciti a dire al nostro cliente che anche i loro requisiti per il numero di persone che avrebbero potuto eventualmente essere rintracciati erano troppo Basso.

Conclusione

Le riscritture a volte sono necessarie e possono essere completate correttamente se la si pianifica correttamente. È possibile andare oltre con riscritture mirate per parti di un sistema rispetto a riscritture per l'intera vendita. Infine, ciò che provoca il fallimento di un progetto non è necessariamente la riscrittura stessa. Mentre non possiamo mai essere chiaroveggenti, possiamo escogitare alcuni scenari peggiori. Ho imparato a progettare i miei sistemi per supportare il doppio dello scenario peggiore che mi viene in mente. Nel caso del sistema di gestione delle crisi, ciò non era abbastanza: i numeri effettivi erano 20 volte lo scenario peggiore che ci era stato dato. Ma quello non era lo scenario peggiore a cui potessimo pensare.

• Le riscritture per motivi di riscrittura non sono tuoi amici. C'è sempre molta complessità che non vedi e scoprirai che le cose brutte che vedi sono strumenti di formazione per il tuo cliente. Mostra sempre i tuoi progressi attuali al tuo cliente a intervalli regolari in modo che possano aiutarti a prendere le offese peggiori.
• Le riscritture mirate sono utili per gestire i peggiori reati nella tua base di codice. Non eseguire una riscrittura completa se è possibile limitare l'ambito e risolvere la maggior parte dei problemi.

Sono stato coinvolto in diverse riscritture che andavano dal VB6 al .NET. In 2 casi le riscritture sono andate bene e in realtà eravamo finiti prima del previsto. L'altra riscrittura ha richiesto più tempo del previsto ma è stata completata senza problemi importanti.

Nel nostro caso particolare la riscrittura NON è stata la decisione peggiore che la nostra azienda potesse prendere. I risultati finali sono stati in realtà molto più stabili rispetto agli originali e ci hanno messo in un posto molto migliore.

Una delle più grandi trappole quando si esegue una riscrittura completa di un sistema esistente è quella di pensare "Non è necessario specificare cosa deve fare il nuovo sistema: è molto semplice, deve solo fare esattamente ciò che fa il vecchio sistema!" .

Il problema è che molto probabilmente nessuno sa esattamente cosa fa il vecchio sistema e passerai innumerevoli ore a far funzionare il tuo nuovo sistema in base al modo in cui i diversi utenti del vecchio sistema pensano che dovrebbe funzionare. Anche i requisiti originali del vecchio sistema probabilmente non sono disponibili.

La mia è una storia di "successo". Il mio progetto riguardava un sito primario con 4 siti satellite gestiti / scritti in modo indipendente (sottodomini con diverse applicazioni su di essi). Avevamo 4 basi utenti primarie (tutte all'interno di directory attive separate) e nessuna aveva un sistema di autenticazione comune. 3 erano applicazioni ben consolidate e silosate e il 4 ° satellite era nuovo di zecca e aveva copiato gran parte della sua base di codice dal nostro sito più consolidato.

Obiettivo: implementare un sistema di identità a livello aziendale in grado di autenticare account su 4 domini e gestire account completi (con self-service) in 1 dei domini. Poiché .Net era già implementato sui satelliti, il classico sito asp che fungeva da "lead-in" avrebbe dovuto essere riscritto, aggiunta la gestione delle identità e tutti i siti avrebbero avuto bisogno di test di regressione per assicurarsi che nessun servizio fosse interessato.

Risorse: 3 architetti primari: programmatore, gestione delle identità, project manager. Circa 20 sviluppatori, 10 analisti, 10 tester.

Tempo per il completamento (dall'inizio alla fine): 1,5 anni

Avvio riuscito : Near Failure

Successo di longevità: eccezionale

Ero l'architetto della gestione delle identità, quindi ho progettato i database, i sottosistemi e le interfacce logiche con cui tutti i satelliti avrebbero interagito. L'architetto "programmatore" era uno sviluppatore principale con una vasta conoscenza commerciale di tutti i satelliti ed esperienza con le applicazioni e il loro sviluppo fino a quel momento.

Dopo diversi mesi di raccolta di requisiti con circa 50 persone diverse provenienti da vari reparti della nostra società, siamo riusciti a far risaltare l'architettura logica e abbiamo iniziato a sborsare il codice. A causa della natura del cambiamento, abbiamo dovuto riscrivere il nostro sito Web e tutte le funzionalità che conteneva in .Net. In alcuni casi era solo una questione di refactoring. In molti casi ha comportato una completa riscrittura dei processi che lo circondano. In 2 casi abbiamo semplicemente abbandonato la funzionalità originale in quanto non importante. Abbiamo perso 2 scadenze nel processo (ma alla fine abbiamo raggiunto la scadenza originale che avevo proposto - a malapena). Il giorno del lancio non ha funzionato nulla. Abbiamo lanciato un sabato, quindi l'impatto è stato minimo, ma ho passato l'intera giornata a esaminare i registri, riscrivere i pezzi e valutare i carichi del server. Altri test potrebbero aver aiutato.

Alla fine del primo giorno, tutti i siti erano attivi e funzionanti e tutto funzionava (direi un successo nominale). Nel corso degli ultimi 2,5 anni, tutto è stato un successo eccezionale. Avere tutti i nostri siti su un'architettura comune con una base framework comune ha reso molto più semplice lo sviluppo e il lavoro tra sviluppatori. Le funzionalità che ho scritto nel nostro sito 2,5 anni fa (durante la nostra riscrittura) sono state viste / adottate da un paio di silos satellitari.

Abbiamo aumentato la registrazione, il tracciamento degli utenti, il tempo di attività aumentato, un'applicazione singolare responsabile dell'autenticazione / autorizzazione / identificazione. I silos satellitari possono concentrarsi interamente sulle loro applicazioni e possono fidarsi che esistano problemi di autenticazione / autorizzazione con l'applicazione di gestione delle identità.

Il nostro progetto è stato un sacco di frustrazione, angoscia e catastrofi. Alla fine ha pagato e poi alcuni. Sono d'accordo al 100% con la valutazione delle riscritture di Joel Spolsky come regola generale, ma ci sono sempre delle eccezioni. Se stai considerando una riscrittura, devi solo assicurarti che sia assolutamente quello di cui hai bisogno. Se lo è, allora preparati a tutti i dolori che ne derivano.

Sono coinvolto in un'enorme riscrittura del codice ora ... l'unico problema è che sono l'unico che ci sta lavorando! I costi di manutenzione del nostro attuale software sono esorbitanti, hanno molti bug e abbiamo 1 dipendente FT che lo mantiene, quindi abbiamo deciso di costruirne uno nostro.

È molto più lento di quanto mi aspettassi, ma alla fine penso che sarà molto meglio perché avremo la nostra base di codice in modo che eventuali cambiamenti che vogliono in futuro possano essere facilmente implementati (il software deve cambiare frequentemente per stare al passo con tempi attuali). Inoltre stiamo apportando alcune importanti modifiche al design mentre lo riscriviamo.

Ho partecipato a una riscrittura completa nel mio lavoro precedente. E siamo stati molto contenti di averlo fatto. Diciamo solo che a volte il codebase è così marcio che è meglio ricominciare.

Era un'applicazione interna, in effetti la principale applicazione aziendale.

Abbiamo mantenuto il vecchio sistema mentre scrivevamo la versione 2. Se ricordo bene, ci sono voluti circa un anno (due programmatori e poi un terzo). Non abbiamo avuto bisogno di toccare il database, quindi almeno la migrazione dei dati non era un problema.

Tutto dipende. Nel mio caso ho seguito il consiglio di Joel Spolsky e mi sbagliavo . Si trattava di un sito Web assicurativo. Il sito è stato orribile ed ecco cosa ho fatto, quindi cosa avrei dovuto fare:

Bad strategia: ho seguito un gruppo di 4 studenti a:

• Studente n. 1: riscrive l'accesso al database / le query per renderle sicure
• Studente n. 2 - spostato tutti i css "su"
• Studente n. 3: ha reso tutte le pagine compatibili con w3c
• Studente n. 4: risolti tutti i bug in sospeso
• Io stesso: rimosso tutti gli avvisi di php e roba scadente (codice duplicato e così via)

Ci sono voluti 2 mesi. Quindi abbiamo riprogettato il sito. Quindi l'abbiamo fatto in più lingue. Tutto sommato abbiamo dovuto mantenere gran parte del codice scadente e la struttura del database è rimasta invariata. Quindi sto ancora lavorando su cose scadenti da un anno ormai e non sarà mai finito fino a quando non decidiamo una riscrittura completa, che non accadrà mai in realtà.

Buona strategia:

• Studia l'intero sito, crea un buon "Documento sui requisiti del prodotto".
• Riprogettare correttamente il database
• Inizia da zero con il mio framework (che già funziona)
• Riprogettato il sito.
• Fai multilingua.

Tempo che ci sarebbe voluto: due mesi ( forse meno ).

• Buon codice
• Buona manutenzione
• Produttività.
• Nessuna risposta come "non possiamo farlo, il sito Web non è in grado di gestire tali prodotti".

Quindi, le mie ultime parole: tutto dipende dalla complessità delle cose che devi riscrivere .

Non esitare a correggere il mio post per renderlo corretto, per favore, grazie mille

Olivier Pons

Una società per cui ho lavorato ha avviato un importante refactoring della base di codice.

Metà della squadra è stata impostata per lavorare sul refattore e l'altra metà ha continuato a mantenere e migliorare il prodotto esistente.

Come puoi immaginare, il refactor non è mai arrivato a un punto in cui qualcosa ha funzionato, è stato solo un processo continuo che non ha mai avuto nulla da mostrare da solo.

L'idea era che la base di codice refactored sarebbe meglio lavorare con noi e potremmo semplicemente "entrare" nelle nuove funzionalità che il team aveva aggiunto al prodotto esistente dopo averlo fatto, e "recuperare".

Ma alla fine è stata la rovina dell'azienda.

Ho fatto una grande riscrittura negli ultimi 3 anni. Originale abbiamo stimato che il progetto durerà 2 anni. L'idea di base era sostituire l'hardware, utilizzare un sistema operativo esistente, riscrivere la logica aziendale (da c a CPP), creare una nuova scheda I / O e scrivere una nuova interfaccia utente.

Lungo la strada abbiamo preso delle decisioni terribili. Non abbiamo avuto esperienza reale in CPP e nessun mentore per insegnarlo bene. Abbiamo provato a costruire noi stessi un framework UI basato su win32. L'hardware era economico e il BSP era difettoso di bug. Il software era super flessibile ma difficile da mantenere. L'anno scorso abbiamo lanciato l'interfaccia utente cresciuta in casa e sviluppato un'interfaccia utente in .net. Abbiamo anche riscritto completamente il nostro meccanismo di persistenza e il protocollo di comunicazione dei dati.

Ci sono voluti molti sforzi extra, ma ora il progetto è quasi finito e le prime unità sono state testate sul campo. Il progetto ha comportato molti rischi per avere qualche cambiamento di successo. Ci sono stati alcuni aspetti positivi del progetto, abbiamo iniziato a utilizzare SVN (anziché VSS), ci siamo presi del tempo per scrivere test unitari e implementare una build notturna. Abbiamo anche iniziato a utilizzare Scrum per avere un processo migliore.

Con il senno di poi penso che la riscrittura della logica aziendale non fosse necessaria, avremmo dovuto solo riconsiderare le parti più brutte. E per scrivere un'interfaccia utente da zero non farlo a meno che non sia il tuo core business.

In realtà sto iniziando un grande refactoring. 4MLocs probabilmente dovrebbe essere ridimensionato a 800KLocs o meno. Questo progetto ha molte funzioni Copia & Incolla, incomprensioni linguistiche, molti e molti commenti inutili ripetitivi, decisioni sbagliate, hacking temporaneo e più hacking resi permanenti (compresi soluzioni alternative), completa mancanza di conoscenza dei principi di base di Informatica o Ingegneria del Software. Probabilmente il team di manutenzione di 32 programmatori difettosi sarà sostituito da 2 buoni programmatori dopo il refactoring.

Ho scritto un motore di blog in 3 settimane. L'ho riscritto in 8 ore.

Pianificare in anticipo è la chiave per una riscrittura riuscita. Conoscere il sistema dentro e fuori è anche un vantaggio.

Poco più di un decennio fa, ho lavorato per un'azienda che ha deciso di fare una "riprogettazione" del loro vecchio prodotto di base. Da allora, menzionare la parola "riprogettazione" è un'offesa punibile. Ci è voluto molto più tempo del previsto, ovviamente costato di più, e il nuovo prodotto era molto più simile al vecchio prodotto di quanto inizialmente previsto.