Vuoi riprogettare completamente sotto .Net?

Un sacco di persone scoraggiano la riscrittura di un'applicazione da zero e talvolta sono d'accordo con il ragionamento. Ma la maggior parte delle volte trovo che la nuova app riscriva la soluzione meno dolorosa e qualsiasi cosa scritta in Access deve essere trasferita su .NET - PERIOD. Non fraintendermi, Access ha il suo posto e può fornire un sacco di funzionalità a un'organizzazione, ma se si trasforma in una vera e propria app su cui le persone fanno affidamento, allora è cresciuto Access.

Probabilmente non ci vorrà molto tempo per eseguire il porting di VBA su .NET in una conversione one for one. Ma potrebbe non essere un'ottima soluzione se il VBA non è molto buono per cominciare. Una riprogettazione / riscrittura richiederà più tempo per scrivere, ma a lungo termine sarà molto più facile da mantenere.

Sono quasi sempre nel campo della riscrittura da zero in cui Access è interessato e non me ne sono mai pentito una volta.

Sono d'accordo con l'approccio del refactoring. È molto probabile che questo sia un processo lento che potrebbe richiedere molti mesi, ma spostando una funzione / sezione alla volta presenta i principali vantaggi, tra cui:

1. Le funzionalità del prodotto sono mantenute.
2. la capacità di fornire una nuova versione viene mantenuta.
3. La pressione temporale è stata rimossa.

Buona fortuna

In genere è una pratica scoraggiata "riscrivere" un'applicazione da zero (che è una normale richiesta che la maggior parte dei programmatori ha sentito almeno un paio di volte nella loro vita) perché si passerà da un'app con set di funzionalità noto (e bug noti) troppo!) a un'app con la più probabile serie di funzioni e, soprattutto, a bug sconosciuti. Gli utenti potrebbero essere frustrati, ecc.

Probabilmente staresti meglio se avessi effettuato il refactoring della tua app per un periodo di tempo, quindi avresti evoluto la sua architettura per un periodo di tempo più lungo.

Una grande sfida che ho sperimentato con una riscrittura di quella scala è il dover mantenere due codebase allo stesso tempo. Se correggi un bug nel sistema legacy, devi assicurarti che la funzionalità funzioni correttamente nel nuovo sistema e viceversa. L'aggiornamento di un modulo alla volta riduce al minimo il mal di testa di manutenzione.

Sarebbe anche utile una suite di test di regressione completa che gira su entrambi i sistemi legacy e di sostituzione.

Sono d'accordo con Jas, non riscrivere le app solo per riscrivere il sake. Potrebbe non essere mai necessario eseguire il debug o il miglioramento, quindi perché perdere tempo? Tuttavia, se ritieni che ci sia un cambiamento commovente nelle competenze del tuo nuovo sviluppatore che si allontana da Access to .NET, potresti dover eseguire la migrazione prima che sia troppo tardi. Sembra improbabile, ma una possibile considerazione.

Anche se potrebbe non essere redditizio dal punto di vista dello sviluppo, in che modo si stanno diffondendo applicazioni diverse che riguardano gli utenti? Richiede più formazione degli utenti? Stanno facendo più errori. Aumenta il numero di chiamate di assistenza perché non riescono a trovare qualcosa?

"Penseresti che spendere tempo e risorse per rinnovare completamente l'applicazione sotto .Net sarebbe più conveniente?"

Questa non è una domanda a cui puoi rispondere qui.

Dall'alto della piramide dei requisiti: qualcuno ha preso una decisione che, si spera, può giustificare con un piano aziendale. In tale piano aziendale dovrebbe indicare quante ore + costi aggiuntivi necessari per convertire l'applicazione e in quello stesso piano aziendale i vantaggi sono indicati anche in termini di denaro.

Questo è il modo di farlo. Se non c'è un piano aziendale per questo. quindi la risposta è di lavorare prima su un piano aziendale riconducibile ad alcuni casi d'uso di alto livello per effettuare l'analisi dell'impatto per verificare l'inizio del progetto.

Se il driver originale dell'obiettivo aziendale che porta al cambiamento non è nemmeno basato sul denaro, allora questa persona è probabilmente quella che paga per tutto, quindi deve essere fatto.

Se non c'è un piano aziendale ma "è fatto" allora prova a crearne uno e presentalo al top management. Includere casi di utilizzo di alto livello, costi, ore di riprogettazione, creazione, costi aggiuntivi per le operazioni, nuova formazione per amministratori e utenti finali, gestione dei progetti e potenziali rischi.

IMHO questa non è una domanda tecnica.