Ti ridisegnare completamente sotto Net?

Question

Una vasta applicazione nasce come un sistema basato su Access (per l'archiviazione di database). Forme sono stati scritti in VB5 e / o VB6. Come Net è diventato un appuntamento fisso nella comunità di sviluppo, alcuni moduli sono stati riscritti. Questo sembra molto scomoda e potenzialmente costoso solo per mantenere a causa delle cross-tecnologie e lavoro extra per mantenere le due tecnologie felice con l'altro. Naturalmente, l'applicazione utilizza un mix di ODBC OleDb e MySql.

pensereste trascorrere il tempo e le risorse per completamente ri-sviluppare l'applicazione in .Net sarebbe più conveniente? Nel tentativo di sviluppare un'applicazione più stabile, non sarebbe senso utilizzare .Net? O continuare a caccia di bug di accesso, l'aggiunta di nuove funzionalità di .Net (che può o non può creare nuovi bug tra .Net e Access), e riscrivendo i moduli di accesso vecchi in .Net moduli sotto vincoli di tempo che impediscono una corretta progettazione e sviluppo?

Aggiorna L'applicazione utilizza OleDb e MySql - ho corretto la mia dichiarazione precedente.

Inoltre, per dare ulteriore sostegno alla riscrittura: allora ho scoperto che quando il "porting" per .Net iniziato, il codice VBA / VB6 che esisteva è stato sostanzialmente tradotto all'equivalente .Net . Dalla mia comprensione, nulla è stato fatto per migliorare le prestazioni, o approfittare delle nuove librerie o tecnologie.

A mio parere, questo crea un'applicazione molto fragile e instabile. Con ogni nuovo aggiornamento, questo diventa sempre più visibile. Come tecnico help desk, ho notato un aumento dei problemi segnalati. I clienti che utilizzano il software hanno notato un aumento dei problemi e sono commentando su di esso.

Answer 1

Un sacco di gente scoraggiare riscrivere un'applicazione da zero e qualche volta sono d'accordo con il ragionamento. Ma la maggior parte delle volte mi trovo rewrting l'applicazione della soluzione e qualsiasi cosa meno dolorosa scritto in Access ha bisogno di essere portato su .NET - PERIODO. Non fraintendetemi, accesso ha il suo posto e in grado di fornire un sacco di funzionalità per un'organizzazione, ma se si trasforma in un'applicazione a tutti gli effetti che la gente fare affidamento su allora è fuori di accesso adulto.

Sarebbe probabilmente ci vuole molto tempo per porto VBA extisting per .NET in un uno per una conversione. Ma questo non può essere una grande soluzione se la VBA non è molto buona per cominciare. Una riprogettazione / riscrittura ci vorrà più tempo per scrivere, ma sarà a lungo andare essere molto più facile da mantenere.

Sono quasi sempre nel campo di riscrivere da zero dove l'accesso è interessato e non sono pentito subito.

Answer 2

Sono d'accordo con l'approccio refactoring. E 'molto probabile che questo sarà un processo lento che può richiedere molti mesi per completare, ma spostando una caratteristica / sezione alla volta ha importanti vantaggi tra cui:

1. Caratteristiche del prodotto vengono mantenuti.
2. capacità di fornire una nuova release è mantenuta.
3. pressione tempo viene rimosso.

In bocca al lupo

Answer 3

E 'generalmente una pratica scoraggiato a "riscrivere" un'applicazione da zero (che è un bisogno normale maggior parte dei programmatori sentito almeno un paio di volte nel corso della loro vita), perché si andrà da un app con nota set di funzionalità (e bug noti troppo) per un app con più serie probabilità minore di funzionalità e più importante -! bug sconosciuti. Gli utenti potrebbero ottenere frustrati, ecc

È probabilmente sarebbe meglio se si refactoring lentamente la vostra applicazione per un periodo di tempo, quindi in continua evoluzione la sua architettura in un periodo di tempo più lungo.

Answer 4

Una grande sfida che ho vissuto con una riscrittura di quella scala si trova a dover mantenere due basi di codice allo stesso tempo. Se si fissa un bug nel sistema legacy, è necessario assicurarsi che la funzionalità funziona correttamente nel nuovo sistema, e viceversa. Aggiornamento di un modulo alla volta riduce al minimo la manutenzione mal di testa.

Una suite di test di regressione completa che viene eseguito su entrambi i sistemi legacy e sostituzione sarebbe anche utile.

Answer 5

Sono d'accordo con Jas, non riscrivere le applicazioni solo per amor riscrittura. Potrebbero mai bisogno di eseguire il debug o migliorato, quindi perché perdere tempo? Tuttavia, se pensate che ci sia un cambiamento in movimento nella competenza dei tuoi nuovi assunti sviluppatori lontano da Access a .NET, potrebbe essere necessario eseguire la migrazione prima che sia troppo tardi. Che sembra improbabile, ma una possibile considerazione.

Anche se non può essere redditizio dal punto di vista dello sviluppo, come sta avendo diverse applicazioni diffuso in tutto interessando gli utenti? C'è bisogno di più formazione degli utenti? Stanno facendo più errori. Fa aumentare il numero di chiamate di assistenza, perché non riescono a trovare qualcosa?

Answer 6

"pensereste trascorrere il tempo e le risorse per completamente ri-sviluppare l'applicazione in .Net sarebbe più conveniente?"

Questa non è una questione che può essere risolta qui.

Dalla cima della piramide requisito: qualcuno ha preso una decisione che egli spera può giustificare con un business plan. In questo business plan dovrebbe indicare quante ore + extra costi che serve per convertire l'applicazione e in quello stesso business plan i benefici sono espressi anche in termini di denaro.

Questo è il modo per farlo. Se non esiste un piano di business per esso. allora la risposta è al primo lavoro su un piano aziendale riconducibile ad alcuni casi d'uso di alto livello per rendere l'analisi di impatto per verificare l'avvio del progetto.

Se il driver originale del obiettivo aziendale che porta al cambiamento non è nemmeno basata sul denaro, allora questa persona è probabilmente quello di pagare per tutto così deve essere fatto.

Se non v'è alcun piano industriale, ma "semplicemente è fatto", quindi provare a fare uno e presentarlo alla gestione superiore. Includere alti casi utilizza il livello, i costi, le ore di riprogettazione, costruire, costo supplementare per le operazioni, una nuova formazione per admin e utenti finali, la gestione dei progetti e dei rischi potenziali.

IMHO questa non è una questione tecnica.