Al momento stiamo supportando un'applicazione desktop ERP obsoleta, non strutturata, non testata e instabile codificata in Windev (su Windows). Con il passare dei giorni, abbiamo bisogno di aggiungere più funzionalità per gli utenti, ma continuiamo a incorrere in problemi terribili, perdita di dati e problemi di integrità. Qualsiasi cosa cerchiamo di implementare al fine di salvarci dalla riscrittura del tutto è costantemente in errore a causa di come l'applicazione è stata strutturata.
Ho il compito di trovare un modo per fondere lentamente una nuova architettura più pulita senza la necessità di chiudere l'attività per una completa riscrittura. Dato che non abbiamo test e che il codice non deve essere testato, il refactoring è estremamente pericoloso perché non siamo coperti da alcuna rete di sicurezza.
La maggior parte dei bug che abbiamo sono correlati ai dati e dal momento che tutte le entità sono accessibili da ogni parte, è davvero difficile correggere i problemi dei dati o assicurarci che sia solido . Gestiamo un ERP, quindi ciò che vendiamo dovrebbe essere un dato affidabile.
L'attuale approccio che sto prendendo in considerazione, sta lentamente fondendo tutto in un'API back-end con una struttura robusta in C #. Il piano è di rendere ogni nuovo database accessibile tramite l'API locale e di unire progressivamente i dati esistenti nell'API. Poiché le risorse correnti sono accessibili da tutta l'applicazione, molte di esse verranno in parte migrate nell'API e in parte ancora codificate nell'applicazione Windev fino a quando tutti gli accessi a una certa entità / endpoint verranno completamente migrati.
I vantaggi che vedo in questo sono che potremo fonderci lentamente attraverso una nuova applicazione e, infine, avere centralizzato tutti gli accessi ai dati che ci consentiranno di testare gli endpoint. Un altro aspetto positivo di questo approccio sarebbe che la maggior parte del lavoro pesante sarebbe fatto se decidessimo di andare in riscrittura dal momento che avremmo solo bisogno di convertire un po 'di logica aziendale e creare una nuova interfaccia utente. Potremmo persino andare sul web se decidessimo di ospitare solo l'API. Le richieste dei clienti non sono bloccate poiché abbiamo solo bisogno di passare nuovi dati nell'API e unire i vecchi accessi ai dati in esso.
Vedo alcuni problemi, incluso il fatto che sarà un problema supportare sia l'applicazione che il server locale per un bel po 'e che potremmo avere un po' di impatto nelle prestazioni, ma sento ancora che gli aspetti positivi sono molto supera i cattivi.
Sono completamente pazzo andando con questo approccio e mi manca qualche ovvia soluzione più pulita.
tieni a mente che il linguaggio di programmazione che stiamo attualmente utilizzando si presenta con un intero ecosistema chiuso in cui siamo bloccati con i suoi strumenti di distribuzione, con il suo linguaggio di query e database con pochissima documentazione e che è estremamente limitato in termini di design pulito. È persino molto difficile essere in grado di applicare i principi dell'OOP, quindi dobbiamo sfuggire a questo ecosistema al più presto