Quali sono le cose importanti da ricordare quando si reingegnerizza un'applicazione legacy?

Scrivi una suite di test unitari per la funzionalità esistente prima . Quando esegui la riscrittura, puoi utilizzare questa suite di test unitaria per verificare che le regole aziendali esistenti funzionino ancora nella nuova applicazione.

Crea un piano di transizione incrementale . Ovvero, fai in modo che il progetto sia sempre in uno stato eseguibile, passando dal vecchio codice al nuovo codice senza entrare nella condizione di richiedere in modo efficace tutto il nuovo codice da scrivere prima che tutto funzioni.

Potrebbero esserci alcune cose ancora fatte "alla vecchia maniera", mentre altre funzionalità sono fatte "alla nuova maniera" e l'interfaccia utente potrebbe essere meno che desiderabile per un po '. Ma questo approccio ridurrà significativamente il tuo rischio, perché puoi sempre spedire qualcosa. (In realtà, se hai una transizione graduale all'interfaccia utente, questo potrebbe funzionare bene con la nozione di Joel l'Effetto Iceberg : la direzione / i clienti vedranno i progressi e avranno un'idea di ciò che resta da fare).

Questo dipende in qualche modo dalle circostanze della tua base di codice, ma guarda attentamente prima di decidere se questa base è l'eccezione alla regola o no, perché probabilmente non lo è.

1. Capire cosa sta facendo il codice base esistente. In qualsiasi vecchia applicazione legacy potrebbe esserci un buon numero di casi speciali che gli utenti si aspettano, diffidare di questi e solo intenzionalmente e razionalmente modificare il comportamento esistente.
2. Accoppiato con 1. devi anche testare che la nuova funzionalità sta facendo ciò che è inteso (in base alla comprensione di ciò che sta facendo attualmente, o cambierà).
3. Se si tratta di una grande applicazione o di una base di codice, pianificare l'introduzione graduale della modifica, questo dovrebbe attenuare il pericolo di una versione di grandi dimensioni e mostrare i progressi.
4. Prestare particolare attenzione se si opera in un ambiente che è eterogeneo nelle versioni del software: attenzione ai formati di file, ai protocolli di rete, ai formati di memoria condivisa. Verifica e assicurati la compatibilità tra le versioni.
5. Se si modifica un sistema di archiviazione dati, prepararsi a eseguire il mirroring delle scritture per un po 'nel nuovo sistema per testare il carico e gradualmente trasferire le letture sul nuovo sistema mantenendo le scritture nel vecchio sistema. Una volta che il nuovo sistema è solido, aggiungi la nuova funzionalità.

Cercando di inventare cose che non sono già state dette:

1. Coinvolgimento della gestione sicura. Ricorda che il successo di un progetto ad alto rischio spesso dipende dal buy-in da parte del management. Assicurati di avere stakeholder legittimi e attivi che lo desiderino male. Altrimenti, potresti incontrare ostacoli seri se incontri resistenza al cambiamento e quando cambierai sistemi, incontrerai resistenza al cambiamento. In un progetto in cui stavamo spostando le persone verso un nuovo sistema, tutto ciò di cui potevano parlare era quanto fosse migliore il vecchio sistema. I dirigenti davano alla gente la possibilità di salire a bordo e, se c'erano dei dissidenti seri, venivano rilasciati. La triste verità è che c'erano parti del vecchio sistema che erano davvero migliori (una lunga storia che è troppo deprimente per me per raccontare qui) ma poiché la gestione era seria, il team di implementazione ha ottenuto il supporto necessario.
2. Proteggi un campione dal lato utente per il progetto. Se il product manager dell'applicazione precedente è a bordo e coinvolto attivamente, questo è un vantaggio. In caso contrario, un utente esperto che è rispettato nella comunità sarà importante. Demarco e Lister hanno detto qualcosa una volta: "Ogni volta che un nuovo sistema arriva online, qualcuno guadagna potere e qualcuno perde potere". Se un buon leader sul lato utente è a bordo, potrebbe potenzialmente facilitare l'accettazione da parte dell'utente.
3. Trattare il nuovo sistema come un nuovo progetto e coinvolgere un buon analista. Quell'analista potrebbe essere uno sviluppatore senior, ma qualunque cosa, non vuoi commettere l'errore di dire "Oh, sarà facile, fai semplicemente quello che fa il vecchio sistema, ma meglio". Il problema è che se il vecchio sistema è qualcosa come la maggior parte di quelli in America aziendale, quindi identificare esattamente "ciò che fa il vecchio sistema" potrebbe non essere così facile come sembra ... probabilmente c'è una documentazione, se non obsoleta, e molti di vecchi e crudeli modi di fare cose nel sistema che potrebbero non essere nemmeno più rilevanti. Molte volte i sistemi fanno le cose solo perché è così che è stato fatto nel vecchio processo manuale, e puoi risparmiare un sacco di lavoro e cancellare un sacco di logiche complicate rimuovendo le complicazioni inutili. A volte il codice migliore è la linea che non scrivi.
4. Guarda prima il componente dei rapporti. Le segnalazioni sono spesso dimenticate o lasciate finire come un ripensamento, ma questo sta perdendo un grande strumento di informazione. I vecchi rapporti del sistema possono dirvi di cosa hanno più bisogno gli utenti e possono essere un buon punto di partenza per verificare quale dovrebbe essere l'output del nuovo sistema. Fai attenzione però a controllare ogni rapporto ... probabilmente alcuni non sono nemmeno più usati.

• Passaggio 1: leggi link
• Passaggio 2: fai in modo che altri ingegneri del tuo ufficio leggano il Passaggio 1
• Passaggio 3: non commettere un errore strategico

Volevo davvero lasciarlo a quei tre passaggi, ma nel caso qualcuno lo prendesse mentre ero pigro, riscrivere da zero è quasi destinato a fallire. Il codice di adattamento e refactoring incrementale è il modo migliore.

Un sacco di buone risposte finora. (Presumo che il sistema esistente sia un guazzabuglio senza speranza o codificato sulla piattaforma sbagliata)

Ecco i miei pensieri:

• Crea il tuo sistema di test! : è probabile che il progetto attuale non ne abbia uno e questo è un ottimo momento per iniziare a fare le cose per bene. Ciò include anche la possibilità di rendere il codice facilmente testabile.

• Definisci il successo in anticipo : quando saprai che il progetto è finito? Senza questo si potrebbe finire per riprodurre gran parte del sistema originale, ma essere impantanati in " solo un'altra cosa " aggiunte alla funzionalità.

• Dì NO ai lavori di sincronizzazione! : ho passato 2 anni della mia vita di sviluppo a ripulire il caos che producevano in una società che tentava di eseguire sistemi side-by-side. Una pianificazione scadente e la mancanza di un buy-in aziendale hanno creato questi lavori e alla fine significativamente hanno rallentato il tempo di sviluppo finale.

Una cosa importante da ricordare quando si ricostruisce da zero è conoscenza del dominio . Le aziende spesso si impegnano in "riscritture complete" - utilizzando le tecnologie e i progetti di sviluppo più recenti per garantire il più alto livello di conformità alle parole chiave - portando a risultati deludenti perché le persone che conoscono di più sull'argomento non sono state consultate in modo approfondito.

Non c'è niente di sbagliato in una completa riscrittura. O per lo più completa riscrittura. C'è un tempo e un posto per loro. Le piattaforme cambiano, le tecnologie cambiano ... a volte devono solo essere fatte. Ma, è meglio farlo sotto la guida delle persone che sono i più esperti sul tema - quelli coinvolti nella precedente implementazione - per le migliori possibilità di un risultato positivo.

Ci sono molte buone risposte qui che sono davvero buoni punti. C'è una cosa che penso sia anche importante. Guarda come la tecnologia è progredita dal punto in cui è stato scritto il codice originale e cosa c'è là fuori adesso:

• Windows Presentation Foundation
• Windows Communication Foundation
• Framework di estensibilità gestita

Con tutti i mezzi, è necessario valutare il codice esistente; unità di test, piano, ricerca, sviluppo, più test. Ma devi anche prendere in considerazione nuove tecnologie che potrebbero prolungare la durata della versione 2.