Prima dell'aggiornamento ...

Potrebbe essere una buona idea se, e solo se:

• it aggiunge funzionalità che i tuoi clienti hanno richiesto ,

• it non perdere nessuna funzione esistente sulla soluzione corrente,

  (alcuni utenti chiederanno loro di formarli, e se sei una piccola azienda, lasciare i clienti sono molto costosi e potrebbero iniziare un'ondata)

• it non aggiunge requisiti invisibili / nascosti e effetti collaterali,

• it non ha vincoli ambientali (o li considera nei calcoli),
• il tuo nuovo middleware di destinazione è attivamente sviluppato e supportato e lo sarà per un (lungo) tempo,
• tu attentamente considera i costi (e vedi successivamente un vantaggio relativamente a breve termine) di:
  • sviluppo,
  • deployment,
  • formazione,
  • manutenzione e amp; supporto,
  • manutenzione e amp; supporto,
  • manutenzione e amp; supporto.

Assicurati che non sarà più difficile da gestire rispetto a adesso.

Inoltre, menziona la tua attuale tecnologia, ma a cosa ti piacerebbe passare. È ancora più pericoloso se sposti le tecnologie.

Se decidi di eseguire l'upgrade ...

Assicurati di:

• backup tuoi dati,
• prova un piano di recupero aziendale ...:
  • a ripristina lo stato di lavoro corrente il più rapidamente possibile se le cose vanno male,
  • per comunicare con i clienti sulla transizione e sui problemi (non riusciti) e sullo stato dei loro dati.

Se esegui l'upgrade (e se possibile) fallo iterativamente!

1. Aggiorna il tuo database o creane uno nuovo,
2. copia sui tuoi dati,
   • aggiorna i tuoi backup regolarmente per lavorare sulle copie recenti,
   • e esegui il backup delle vecchie copie e anche (crittografate in modo sicuro, ecc ...)
3. Sviluppa in un ambiente separato ,
4. prova internamente molto ,
5. test con un gruppo di focus di alcuni clienti fidati.

Se è necessario un completo switch di middleware, controlla se ci sono storie di successo di migrazioni tra queste 2 soluzioni software e leggi attentamente cosa hanno fatto le altre persone e quali trappole e difficoltà incontrate.

Refactor and Monitor Quality

Se è solo (o quasi) del codice disordinato, non farlo . Invece:

• Leggi la mia risposta su come organizzare il codice dirty, non commentato (si applica a frammenti di codice specifici, ma anche a codebase più grandi, e il materiale consigliato potrebbe essere d'aiuto!)
• Solo refactor nel tempo,
• Utilizza i integrazione continua e ispezione continua per monitorare la qualità e gli impatti del refactoring,
• E cerca di contattare i clienti per chiederti chiaramente quali caratteristiche mancano e costruisci un solido caso aziendale attorno a ciascuno di essi per sapere se ne vale la pena per piccoli progetti di miglioramento.

Lo sviluppo è costoso, la manutenzione ancora di più e la creazione di materiale senza particolari motivi potrebbe essere utile per soddisfare gli utenti, ma ricorda che dovrai mantenerlo e supportarlo.

Inoltre, se non sei un'azienda di software, hai abbastanza personale addestrato per supportare questa attività durante lo sviluppo e dopo l'implementazione? Cosa succede se parte del tuo staff si trova nel bel mezzo del compito?

I progetti falliti di cui Joel Spolsky ha scritto sono state delle grandi imprese. Per i pochi esempi che ha fornito ci sono alcuni esempi di successi di riscrittura:

• Mac OS X
• Windows NT

Ora Windows è stato riscritto più di una volta, e ogni volta è stato perso se le modifiche sarebbero state ben recepite o meno. Ad esempio, NT è stato un successo in quanto ha reso Windows utilizzabile in Enterprise (dove Unix ha vissuto prima). D'altra parte Vista non è stato ricevuto altrettanto bene. Tuttavia, in entrambi i casi, Microsoft ha coperto le proprie scommesse.

Il punto che Spoelski fa è che una riscrittura del software è una proposta incredibilmente rischiosa . Con l'aumentare della complessità del progetto, il rischio aumenta esponenzialmente.

Il contrappunto con Brooks e il commento di fare uno da buttar via è che la prima versione di qualsiasi cosa è un processo di apprendimento. Cercando di trattarlo come qualcosa di più di un processo di apprendimento, ti bloccherai per un lungo periodo nel codice sbagliato. In Pragmatic Programmer e in molte altre fonti, il piccolo refactoring per ripulire le decisioni sbagliate è molto meno rischioso rispetto alle riscritture su scala intera.

Ora, nella tua situazione devi guardare le scelte di fronte a te. Hai le seguenti sfide:

• Il tuo software attuale si basa su una piattaforma obsoleta
• Le piattaforme più recenti risolvono i problemi che avevi con la tua piattaforma attuale e in modo più completo
• Il cambio di piattaforma è rischioso
• I rrriti hanno bisogno di pianificazione, o loro falliranno

Prima di prendere in considerazione una riscrittura, devi rispondere ad alcune domande:

• Questo software è già prossimo alla fine della sua vita? (ad esempio se ha una durata di conservazione limitata, il costo e il rischio associati alla modifica della piattaforma potrebbero non valerne la pena)
• Il software è semplice / piccolo? Più è grande il software o più è complesso, più cose che possono e non vanno a buon fine.
• La tua piattaforma di destinazione è in grado di fare tutto il necessario? Per valutare questo, potrebbe valere la pena semplicemente fare le cose discutibili per vedere se è fattibile. Potrebbe essere possibile, ma ugualmente brutto come quello che hai ora. Meglio scoprire con un test controllato che dopo aver preso la decisione.
• Per quanto tempo il tuo cliente può attendere tra una release e l'altra? Se è possibile eseguire una riscrittura completa nello stesso ciclo di rilascio (o più rapidamente), probabilmente non è una soluzione. Tuttavia, la maggior parte dei clienti non si preoccupa dei tuoi problemi e non vedono i tuoi problemi come i loro problemi. Non vorranno aspettare mentre esegui una riscrittura completa.

Ho seguito questo esercizio più di una volta, ea volte è uscito in favore di una riscrittura ea volte è uscito in favore del mantenimento dello status quo. Diverse volte, abbiamo scoperto che se avessimo riscritto solo una parte dell'app, avremmo potuto ridurre in modo significativo il nostro dolore fornendo al tempo stesso valore al cliente.

Migrazione incrementale

Il punto sul non riscrivere da zero è che rischi di rovinare tutto il tuo prodotto attraverso specifiche instabili, elenchi di bug in fuga, ecc. e il tempo / i costi che dovresti spendere con niente disponibile da mostrare per il tuo lavoro è difficile da giustificare.

Poiché stai già utilizzando ASP, ti consiglio di implementare nuove parti del sito in ASP.NET e di spostare gradualmente le pagine meno recenti nel framework più recente man mano che le aggiorni. Lo abbiamo fatto con un prodotto legacy e in 18 mesi l'abbiamo completamente migrato, ma potremmo spedire un aggiornamento ogni due settimane per tenere il passo con la domanda dei clienti.

L'intera idea di una completa riscrittura è che non c'è nulla, nessuna singola cosa, di valore in qualsiasi punto del codice esistente. In effetti l'intera idea era imperfetta e doveva essere eliminata dalla terra.

Nella mia esperienza, questo è raramente il caso. Generalmente è solo obsoleto, e deve essere dato un nuovo strato di vernice attraverso una transizione verso una piattaforma meno obsoleta. Le applicazioni precedenti rappresentano quasi tutti uno strato fossilizzato di comportamenti e ottimizzazione dell'apprendimento. Sono strati su strati di miglioramenti incrementali nel tentativo di raggiungere un picco funzionale. Ignora questo processo a tuo rischio e pericolo.

Troppo spesso vedo le persone impegnarsi in una "completa riscrittura" e quindi riscrivere l'applicazione al primo giorno del suo ciclo di miglioramento, senza incorporare alcuna delle lezioni o miglioramenti ottenuti in anni di attività. Sì, quella roba è orribile che si aggira su una base di codice altrimenti pulita, ma è lì perché la base di codice originale era insufficiente. Sì, riscrivi, ma incorpora le cose che risultavano mancanti nell'idea originale. Il software migliore viene in questo modo: incorporando le lezioni apprese in versioni inferiori in una versione più perfetta.

È è la saggezza convenzionale che fare una riscrittura è una cattiva idea. E per una buona ragione. Le ri-scritture in piena regola sono generalmente una cattiva idea e spesso falliscono in modo spettacolare.

Ma un modo migliore per dichiarare il consiglio è ... "Una completa riscrittura è sempre una cattiva idea, tranne quando è una buona idea".

Non sostituire la saggezza convenzionale per il giudizio personale (o della tua squadra) su ciò che è meglio per l'applicazione tua . Un semplice bit di saggezza convenzionale non può e non si applica alle situazioni tutte . Sta a te valutare per te stesso - tenendo presente gli avvertimenti forniti da altri - se è necessaria o meno una riscrittura. Nessun altro qui sa tanto della tua applicazione e degli obiettivi del tuo progetto come tu fai.

Non sembra che tu stia facendo una riscrittura completa, più che stai spostando la tua attività su una nuova piattaforma che già implementa funzionalità esistenti, che è molto più sana della riscrittura di un nuovo sistema interamente da zero. Fallo! ... e assicurati di avere piani di backup, piani di recupero, provare e testare la transizione più volte (in un corretto ambiente di test isolato), ottenere alcuni test di usabilità fatti sulla nuova piattaforma, ecc ...

Molte operazioni commerciali da una piattaforma all'altra. So che ci sono aziende finanziarie che stanno migrando dai loro sistemi mainframe COBOL ed è molto più grande di un semplice database e di una transizione di progettazione dell'interfaccia utente. Ma è anche essenziale.

La domanda riguarda quale strategia è "migliore", giusto? Come puoi vedere dalle risposte qui, ci sono pro e contro per entrambi. Quindi come decidi? La mia risposta è che devi fare una corretta analisi dei rischi. È inoltre necessario valutare le conseguenze a due livelli: una prospettiva a breve termine e una a lungo termine, che ha a che fare con la durata prevista del sistema o del prodotto. Tutto si riduce a prendere la via più economica, e per farlo bisogna sapere quanto (tempo) costi e costi (in termini di costi) sono coinvolti. Questo non è un compito facile, ma deve essere fatto se ti piace prendere una decisione aziendale valida piuttosto che un'ipotesi plausibile.

Attenzione alle risposte categoriali.

Mi trovo di fronte a un problema simile con un'applicazione Web di Java Struts disordinata. Ho intenzione di riscrivere l'intero sito in tempo, ma non posso smettere di migliorare il codice esistente. Invece, ho intenzione di sviluppare nuove pagine con un'architettura migliore e di migrare le vecchie pagine quando devo toccarle o quando non ci sono attività urgenti.

Sono un sostenitore delle riscritture, contrariamente al consiglio di Joel. Questo è principalmente dovuto al fatto che ho incontrato troppi sistemi che erano nettamente sbagliati e che erano stati "sbagliati" per così tanto tempo che sarebbe impossibile a rifattorizzare tutto ciò che doveva essere risolto. E intendo "tutto": il database era cattivo, il codice era scarso e non riutilizzabile, fino all'uso di HTML / CSS obsoleti. Quando qualcosa è così brutto, il refactoring è come un duct taping di una pipe che perde - tu vorrà sostituirlo ad un certo punto, e farlo prima e dopo ti farà risparmiare tempo e denaro. Ho visto in prima persona gli effetti del seguire il mantra "riscrivi sono cattivi", e il risultato finale è stato quando il sistema si è schiantato definitivamente, si è schiantato in modo spettacolare e ha trascinato l'azienda in bancarotta, perché nessuno poteva vedere che le cose erano strong> orribile e una riscrittura sarebbe stata l'unica cosa che salvava.

Per rispondere alla domanda dell'OP, se il sito non può essere sostenibile per il futuro, se sta utilizzando tecnologie obsolete che non sono più supportate (rendendo più difficile convincere la gente a mantenerlo), allora è il momento di considerare un riscrivere. Indipendentemente dal fatto che si tratti di una società di software o meno non è rilevante come la domanda se ciò che si salva ( LONGTERM , non cadere nella trappola di pensare a breve termine, è quella trappola che fa sì che i sistemi stagnare e infastidire, in primo luogo!) eseguendo una riscrittura, supererà il bagaglio aggiunto di mantenere un sistema malato terminale.