Nel mio ufficio, stiamo per intraprendere un epico viaggio di conversione di una vecchia applicazione Delphi 5 in qualcosa di più moderno. Una delle nostre opzioni è quella di convertire in Delphi Prism, ma vogliamo vedere quali opzioni sono disponibili per aiutarci. Finora, tutto quello che ho trovato è Oxidizer (l'ultimo ha funzionato 2 anni fa). Ci sono altre opzioni per aiutarci a convertirci abbastanza velocemente in Prism? Grazie.
Come molti commenti suggeriscono e incoraggiano, riscrivi, sì. Perché? Molte di queste ragioni sono state menzionate nei commenti, in particolare il declino del supporto diretto alla lingua e agli strumenti, il supporto di terze parti, ma non è nemmeno menzionato il declino dei talenti disponibili per mantenere la nave in funzione. È lo stesso problema a cui sono confrontati molti dei progetti del periodo mainframe e dei progetti derivati diretti: il talento e l'interesse per questi tipi di sistemi stanno calando.
Una delle più grandi sfide per uno sforzo di migrazione non è quale linguaggio o piattaforma o set di strumenti, specialmente oggi: ci sono molte buone opzioni, alcune migliori di altre a seconda di ciò che si sta cercando di realizzare e aspettarsi da lo sforzo risultante. Oggi la sfida più grande, come lo è stata per anni, è trovare il talento giusto per tradurre il vecchio sistema nel nuovo, o almeno tradurlo abbastanza bene e abbastanza efficientemente da permettere agli altri di costruire nel nuovo.
Nel caso dell'OP, sembra che abbiano non solo esperti professionisti non solo nella lingua e negli strumenti legacy, ma anche in grado di familiarizzare con il cliente e il dominio. Questo è un grande vantaggio.
Quello che suggerisco, in base alla mia esperienza con progetti di migrazione legacy autentici, è un salto più grande mentre ci sono competenze sul lato originario. Diventa monumentalmente più difficile quando quei costruttori e manutentori se ne vanno.
Utilizzo del sistema e valutazione della stabilità. Il sistema sta facendo le cose di cui ha bisogno il cliente, né più né meno? I loro pezzi particolari possono essere isolati in una certa misura? Ci sono pezzi che hanno afflitto lo sviluppo perché sono soggetti a rotture o lamentano frequenti reclami? Ci sono frammenti dal punto di vista dell'utente che mancano (utilizzare casi che si adattano allo scope del sistema che non sono stati identificati in altro modo)? E così via ...
Utilizza queste informazioni dalla valutazione dell'uso e della stabilità per avviare un progetto di incubazione, spin-off, per arrivare a una piattaforma più tradizionale a cui gli strumenti e la formazione saranno abbondanti per il prossimo futuro. Usa un mix di architettura / reingegnerizzazione e porting diretto per decollare.
Dimostra i nuovi pezzi utilizzando la distribuzione phased e selettiva per gli utenti.
Valuta i progressi nello sforzo speso.
Aumenta la migrazione se tutto procede come previsto.
EDIT:
Consigli personali:
C # su una piattaforma Windows o web in quanto fornisce familiarità in molti modi a Delphi, e sarà il cavallo di battaglia di Microsoft per un po '.
Forse un'incursione nel cellulare. Dipende da ciò che il cliente ha bisogno e vuole in quanto ciò potrebbe cambiare il modo in cui darei la priorità. Una delle cose che ThoughtWorks Radar suggerisce è che molte aziende si stanno spostando verso una strategia mobile-first per nuovi progetti. Personalmente sarei più propenso a suggerire il percorso di Android se guardi le app native, principalmente perché è pervasivo, ma anche nel caso dell'OP, Java mobile sarebbe una transizione abbastanza comoda da Delphi. Google non si sta allontanando da questo in qualunque momento presto.
Ada. Sto scherzando.
Forse Python o Ruby. Sono un po 'agnostico per entrambi, ma certamente hanno qualche merito.
Leggi altre domande sui tag delphi