Dovremmo riscriverlo da zero

Se non fornisci motivi tecnici per cui non sei soddisfatto della soluzione corrente e, a meno che non valuti il lato finanziario della riscrittura, tutto ciò che otterrai qui sarà un'opinione basata solo sulle preferenze personali. Che è, inutile dirlo, qualcosa su cui nessuna decisione aziendale dovrebbe basarsi in generale.

Modifica: per elaborare un po 'sul già detto, generalmente il processo di decisione di una riscrittura va in questo modo (in questo ordine):

1. Cosa c'è che non va nella soluzione attuale? C'è una lista di problemi reali con esso? Prestazione? Il cliente chiede funzionalità diverse da implementare, se possibile? O sei semplicemente insoddisfatto / annoiato con la tecnologia attuale (questo è un caso spesso con personale tecnico che vuole lavorare con le nuove tecnologie).

2. In cosa "dipende" la soluzione corrente? Tecnologie proprietarie? Ci sono alternative a quelli in lingua B (in cui si desidera riscriverlo). È possibile eseguire una riscrittura piuttosto diretta di codebase o una grande parte di esso deve essere strutturata in modo diverso (in base all'architettura).

3. Il personale attuale conosce il linguaggio B? In caso contrario, c'è abbastanza personale disponibile nell'area in cui risiede la tua azienda? Supporto commerciale per la lingua B - esiste? (Non fare affidamento su comunità di volontari per progetti a lungo termine: passano da una tecnologia all'altra man mano che cambiano i loro interessi. Per una durata di applicazione di due decadi occorrono solide basi in termini di supporto commerciale.)

4. Quanti client dipendono dalla soluzione corrente? I costi del loro trasferimento (dovrai fornire supporto tecnico) a una nuova soluzione? I costi di dare supporto per quanti anni a quelli che non sono stati aggiornati?

5. Analisi finanziaria dell'intera faccenda (è meglio farlo da qualcuno a livello manageriale, prendi atto del fatto che se c'è una cosa che apprezza e sa come stimarla è costi.)

Ho deliberatamente evitato i dettagli qui perché non ne hai dato molti nella tua domanda. Inoltre c'è probabilmente più che ho dimenticato di menzionare ... ma sono le 2 nella mia parte del mondo e sto iniziando a ottenere ... zzz < - sleepy

Onestamente, hai bisogno di una giustificazione molto migliore di "Riteniamo che non sia aggiornato" per giustificare la spesa della somma di denaro che costerà. Quali sono i problemi con l'attuale incarnazione?

Anche se sono d'accordo con tutti i colleghi programmatori, ho anche bisogno di introdurre aspetti meno tangibili ma comunque importanti in questa situazione. Lo sviluppo del software è una disciplina relativamente giovane e cambia velocemente, molto velocemente. Qual è l'età media della tua squadra di sviluppo? 45? Immagina di assumere laureati universitari per lavorare sul tuo stack, prevedi qualche difficoltà? Il tuo stack attuale è favorevole a un rapido sviluppo ea cicli di iterazione brevi? Hai test di unità e integrazione? È persino possibile averli con Oracle Forms? La tua squadra di sviluppo è eccitata (non in hybris e / o nel senso selvaggio del mondo) per venire al lavoro e aumentare il sistema? In questo momento conosci il tuo sistema e i requisiti di base molto meglio di quello che hai fatto nella fase iniziale. Vuoi ancora andare con il tuo stack attuale? Esistono ora strumenti e prodotti significativamente migliori per ottenere ciò di cui hai bisogno in un modo più economico e pragmatico?

Questo è solo uno spunto di riflessione. Se ti imbarchi per una riscrittura, fai un favore a te stesso: cerca di renderlo il più possibile iterativo e resisti all'approccio del "big bang". Parlo per esperienza.

In generale, è meglio evitare di prendere tali decisioni in base ai sentimenti. Solo perché la tecnologia è vecchia non significa che debba essere sostituita. La vecchia tecnologia tende ad essere una tecnologia collaudata. La domanda di solito si riduce ai costi coinvolti.

È necessario determinare quali problemi si stanno avendo con la soluzione esistente e quanto costa il business. È necessario determinare quanto costerà riscriverlo. Confronta i due e usalo per aiutarti a prendere una decisione. (Si noti che non tutto il costo è necessariamente in termini di denaro o può essere facilmente quantificato. Quindi, questo non è esattamente un paragone facile da fare.)

Il software di riscrittura tende a richiedere più tempo e costa più del previsto. Inoltre, non vi è alcuna garanzia che sarà effettivamente migliore della soluzione esistente. Non dire la mia parola su questo, Joel Spolsky ha scritto sul blog perché riscrivere il software da zero è un errore da molto tempo fa.

Quindi, se possibile, dovrebbe essere adottato un approccio incrementale. Piuttosto che raschiare l'intera faccenda e ricominciare da capo, apporta modifiche lentamente e migra la soluzione a una nuova tecnologia pezzo per pezzo.

La risposta breve a questa domanda, imho, è no. Dovresti cercare soluzioni esistenti, siano esse open source o commerciali. Mi sono seduto in riunioni con gli sviluppatori e ho ascoltato affermazioni come "Penso che la tecnologia X sia spazzatura totale, potrei scrivere un prodotto migliore di quello!". La verità è che probabilmente lo possono fare, ma sono nel business che stanno sviluppando le proprie strutture? Scrivere da zero dovrebbe essere l'ultima risorsa, a meno che non si tratti di un dominio esoterico in cui le soluzioni software esistenti sono scarse.

It's a technology from the past decade and we must move the software to a different platform (ie. Web or some other platform).

Guardando questo, sembra che la tua azienda abbia riconosciuto che vi è un pesante bagaglio associato al prodotto che sta utilizzando e che c'è il desiderio di passare a qualcos'altro. Sembra anche che tu sia indeciso su quale piattaforma spostare, quindi devi fare un passo indietro e pensare ai tuoi clienti, quali sono i loro scenari di caso d'uso e poi considerare quale piattaforma / mezzo sarebbe l'approccio migliore per fornire un forma riveduta di ciò che hai attualmente.