Alternative di riscrittura del software [duplicato]

È vero che la riscrittura è l'approccio più radicale e dovrebbe essere evitato quando possibile.

Prova a creare un livello intermedio tra l'applicazione e il DB. Non è necessario che sia necessariamente un progetto separato, ma tutte le richieste di DB dovrebbero attraversarlo. Se riesci a fare questo primo passo, sarà facile cambiare il DB in qualsiasi momento, dovrai solo riscrivere un singolo modulo del tuo progetto.

Una volta fatto questo, prova a dividere il tuo progetto in piccoli pezzi logici e riscrivili ("traduci") uno dopo l'altro (se pensi davvero che non possa essere evitato). Se hai dei test unitari, ti saranno di grande aiuto.

Prima di prendere qualsiasi decisione in merito all'approccio che vorresti intraprendere, ritengo sempre importante che il team di sviluppo consideri sempre l'opzione di una completa riscrittura come una possibilità, anche se molti pensano che sia quasi sempre una cattiva scelta.

Prenditi del tempo per scrivere alcune pietre miliari di alto livello che devono essere raggiunte e prendere decisioni architettoniche di altissimo livello su quali tecnologie di base comprenderanno il nuovo software. A questo punto, fai una stima approssimativa del tempo che ritieni necessario per completare un progetto del genere. Va bene, non importa quale sia la tua scelta, almeno hai una buona idea di quanto uno sforzo di riscrittura ti costerà in termini di tempo e denaro.

L'altro costo molto importante di una riscrittura che molti trascurano di considerare può essere il costo esorbitante del dispiegamento in termini di tempo, denaro e ore lavorative. Gli utenti si sentono a proprio agio con l'utilizzo di vecchi sistemi imperfetti, memorizzano le stranezze e gli errori, i workaround diventano parte della loro routine, memorizzano i tasti di scelta rapida per eseguire rapidamente i loro compiti preferiti, diventano sorprendentemente produttivi nel tempo.

Ho visto riscrivere che secondo tutti gli account avrebbe dovuto essere un grande successo, lo sviluppo è arrivato sotto il tempo e sotto budget, i principali problemi non esistono più, il nuovo sistema era più facile ed economico trovare talenti da mantenere, l'apprendimento la curva era più piccola ... l'unico problema principale che era stato trascurato era l'adozione da parte degli utenti e il coinvolgimento degli utenti basato su Agile. Quando gli è stato detto che il loro sistema mainframe basato su testo era stato sostituito con un client desktop basato su GUI, non avevano familiarità con esso e la produttività è diminuita. L'input dell'utente proveniva solo da un singolo individuo che non svolgeva più queste funzioni di lavoro, quindi combinazioni di tasti importanti, mancanza di supporto della tastiera, tasti di scelta rapida, ordine scadente delle schede e la necessità di un sacco di interazioni tra mouse e mouse fanno precipitare la produttività. Certo, alla fine sarebbero diventati comodi e produttivi, e senza i principali bug e le migliori prestazioni sarebbero stati molto più produttivi con il nuovo sistema basato su GUI una volta che i nodi fossero stati risolti.

Ciò che purtroppo è accaduto è che c'è stata una rivolta aperta contro il nuovo sistema, e nonostante il management buy-in, non potevano costringere gli utenti sul campo ad adottarlo. Il progetto non è riuscito alla distribuzione. I costi nascosti e i rischi legati alla distribuzione e all'addestramento per una riscrittura sono importanti da considerare se confrontati con il costo crescente della manutenzione del sistema legacy.

Un'altra opzione da considerare è quella di esaminare le tecnologie che causano più dolore, la più costosa licenza, il talento più difficile da trovare, intrinsecamente bug, ecc. Un buon inizio potrebbe essere riscrivere piccoli pezzi dell'applicazione in un modo per disaccoppiare i componenti principali. Una volta fatto, è più facile scambiare e sostituire componenti man mano che il tempo diventa disponibile per riscriverli, e ciò riduce notevolmente il rischio di refactoring in generale.

Se fossi in te, inizierei con la sostituzione del solo database. Puoi usarne uno che è più popolare e che è più facilmente gestibile dal pool di talenti. Quando si sostituisce lo schema, è possibile iniziare lentamente a separare la logica specifica dell'accesso al database in moduli separati, rendendo più semplice il disaccoppiamento della logica di business dall'implementazione del database e dal codice di accesso al database. Può essere giustificato in termini di miglioramento delle prestazioni, riduzione dei costi di manutenzione e tempi di risposta più rapidi.

Alcuni pensieri casuali:

Le riscritture del Big Bang sono soggette a problemi di big bang, motivo per cui molte persone suggeriscono un approccio incrementale per riscrivere un'applicazione. Idealmente, quindi, devi Dividere e conquistare .

Se hai intenzione di un approccio incrementale, le sfide sono:

• Come dividi l'applicazione esistente in componenti aggiornabili
• Come aggiorni ciascun componente
• Come si integrano i nuovi componenti con quelli vecchi

Cerca divisioni logiche che già esistono nell'applicazione. Ci sono pezzi di hardware separati? Diverse tecnologie? Livelli? Serve diverse classi di utenti aziendali? O eseguire diversi gruppi di funzioni aziendali?

Il meglio è organizzato il codice originale, più facile sarà il tuo compito. Di conseguenza, suddividere un'applicazione in questo modo comporterà quasi certamente una certa quantità di refactoring dell'applicazione originale. Ad esempio, estraendo le chiamate al database in un singolo set di moduli / classi. Tieni presente che non stai provando a migliorare la tua vecchia applicazione: il tuo scopo è semplicemente la modularizzazione. La risoluzione di altri problemi dovrebbe essere più semplice nella nuova tecnologia (dopotutto, presumibilmente è una delle ragioni per cui stai migrando in primo luogo).

Più piccoli sono i pezzi che hai a che fare e più facile sarà il tuo compito. Quindi prendi le cose un passo alla volta. Anche se gestisci solo poche centinaia di righe di codice, almeno questo è un inizio.

Se puoi automatizzare il processo di aggiornamento in qualsiasi modo, allora fallo. Ad esempio, potresti essere in grado di acquistare / creare uno strumento per convertire codice di programma o schemi di database.

Scrivi test unitari per codice vecchio e nuovo.

Il tuo approccio suggerito - encapsulate the legacy stuff behind a webservice è una buona pratica da seguire. assicurerà che la logica di business rimarrà invariata e ridurrà al minimo i tempi di sviluppo per un'applicazione di aspetto migliore.

Considera alcuni database No-Sql attualmente disponibili sul mercato.

Attualmente, stiamo utilizzando Raven DB per le esigenze del progetto. Anche se, è strano smettere di iniziare a farlo. Tuttavia, sembra uscire da una buona corrispondenza per un puro approccio DDD.

Ecco un post che spiega i lati forti di Raven DB tra i database No-Sql - Perché Raven DB?

Due problemi.

Uno, il problema della squadra della tigre. Di solito questi sviluppi falliscono perché il vecchio sistema sarebbe il requisito per il nuovo, mentre anche quello vecchio cambia, è un paradosso di Zenone. Uncle Bob ha scritto un articolo su questo, ma è anche parte di alcuni dei suoi discorsi e forse anche alcuni dei suoi libri.

In secondo luogo, il problema dell'interfaccia utente.

Non è solo che le persone sono abituate all'interfaccia utente. Questa è la punta dell'iceberg.

Per gli utenti, il sistema è l'interfaccia utente . Ecco perché è stato chiamato "interfaccia utente" al primo posto. Non capisco nemmeno come possano odiare il sistema di database sottostante , dato che non hanno nulla a che fare con esso? Non sta mentendo "sotto" abbastanza?

Se l'interfaccia utente, il comportamento, i dati, e le prestazioni rimangono invariate, è possibile modificare ogni bit del sistema, gli utenti non prenderebbero nota. Potresti convertirlo da Borland Pascal a Turbo C e viceversa, potresti cambiare il SO del server da FreeBSD a Solaris, da Windows a Linux, da Intel a PPC, qualunque sia.

E questo è buono e cattivo per te. Finché, mantieni l'interfaccia utente, puoi modificare il sistema. Se cambi l'interfaccia, assicurati che la logica rimanga la stessa indietro per un po 'di tempo.

(Il tuo unico problema sarà che gli utenti non hanno problemi con il sistema sottostante: hanno un problema con la sua interfaccia utente. Ogni singola richiesta di modifica avviata dall'utente è basata sull'interfaccia utente, questo è ciò che SVN / I registri di CVS / git mostrano tutti i sistemi, perché quella è la lingua che l'utente parla.)

È come il refactoring: si modifica la struttura del codice, ma non si modifica il comportamento o si modifica il comportamento, ma non si modifica la struttura del codice. E avere test automatici per questo.

Non so come si può testarlo, di solito abbiamo usato gli screenshot per applicazioni praticamente vecchie. Ho persino visto il frontend bancario che letteralmente digitava i risultati di una sottomissione di modulo in un terminale al vecchio codice. Non scherzando.

Cambia un passo alla volta. Avere un sistema ibrido per un po '. Cambia UI, mantieni il sistema, cambia sistema, mantieni l'interfaccia utente, cambia l'interfaccia, conserva il sistema, cambia sistema, mantieni l'interfaccia utente ...

È positivo che tu abbia la fonte. Anche se è Pascal, ti rende più facile la vita di qualche miliardo di magnitudini.

Per un refactoring, ho raccolto tutti gli input che il sistema ha avuto in un periodo di test intensivo di mezz'ora e ho raccolto tutte le modifiche al database che doveva fare. Puoi leggere a riguardo qui

Forse dovresti raccogliere l'uso reale del sistema, mediante l'uso di keylogger e di cattura del terminale come kibitz o sceneggiatura .

Oh, e prega che i tuoi test coprano tutto.