Quando si riscrivono applicazioni medio-grandi, quali di questi approcci sono utili?

Le tecniche di sviluppo cambiano e migliorano continuamente, quindi se stai eseguendo una riscrittura, è improbabile che tu voglia semplicemente copiare la struttura del codice corrente. Pertanto, ti suggerisco di escludere gli approcci Clone funzionale (dev view) , Forensics e Analisi del percorso . Questi probabilmente porteranno alla duplicazione di parti del codice errate, oltre al bene.

Gli altri due approcci devono essere usati insieme:

Clone funzionale (visualizzazione utente) Stai per iniziare da zero, quindi parlando con gli utenti in primo piano puoi:

• Cogli l'occasione per scoprire se sono realmente necessarie tutte le funzionalità dell'app attuale e se ci sono caratteristiche mancanti che hanno sempre desiderato.
• Assegna la priorità all'ordine in cui verranno aggiunte le funzionalità e definisci un Prodotto minimo vitale, che formerà la prima versione.

Riga per riga Mentre richiede molto tempo, esaminare ciò che l'app corrente è utile. Aiuta a catturare i requisiti, in quanto gli utenti potrebbero non essere consapevoli del fatto che esistano funzionalità dietro le quinte o dimenticare quella funzionalità vitale che utilizzano solo a fine anno, ad esempio. Questa analisi dovrebbe essere utilizzata solo per l'acquisizione dei requisiti, a meno che parte del codice possa essere riutilizzata nella nuova versione. Evitare la copia riga per riga delle funzionalità, soprattutto se si cambiano le lingue. Questo porta a un codice non idiomatico, difficile da mantenere,

Frammenti di lucidatura

A, un po 'fuori tema (anche se lo hai citato), punto di chiusura, è che l'affermazione "non puoi lucidare una stronza" non è vera. Cerca semplicemente "coprolite levigata" per esempi di tali feci fossilizzate lucidate ...

Una riscrittura deve offrire valore agli utenti. Questo è un must. Se dichiari semplicemente che un'app è troppo difficile da mantenere, c'è troppo debito tecnico, eccetera, i tuoi sponsor ti guarderanno e ti chiederanno: "Beh, chi è stato in quel modo?" E questa è una buona domanda. Perché scrivere un assegno alla stessa squadra che l'ha rovinato l'ultima volta? Cosa c'è di diverso?

Ecco dove un cambiamento nel tuo modo di pensare potrebbe tornare utile. Non è semplicemente una riscrittura; è la versione X di Badass App!

Non c'è nessuna vista oltre alla vista utente.

E non è un clone funzionale. Non può essere. Deve essere migliore di quello. Tutti i fastidi - clic in più, navigazione goffa, UI brutta, in attesa - devi risolverli. Tutte le richieste di funzionalità che avrebbero compromesso il design dell'app originale: devi dimostrare di aver compreso gli obiettivi degli utenti così bene che tali funzioni si integrano perfettamente nel tuo nuovo design. Questo, o dimostri che ora sai così tanto che capisci chiaramente che non esiste una realtà alternativa nel multiverso in cui la funzione Y potrebbe esistere nella versione X di Badass App.

Riguardo al clone funzionale (dev view) e Forensics , fai un favore a te stesso e riconsidera assolutamente ogni nome e relazione. Costruisci modelli migliorati in base a ciò che hai imparato. Non copiare nulla finché non è stato controllato dal tuo team estremamente ponderato e profondo.

Infine, non abbiamo individuato l'applicazione "medio-grande". Immagino che ci siano opportunità per una riprogettazione incrementale rispetto all'approccio del big bang. Ci sono servizi? Se è così, forse questo è un buon momento per intrattenere un approccio di microservizio. Crea il tuo primo microservizio usando la tua nuova tecnologia. Mentre ci sei, estrai la logica aziendale dall'interfaccia utente in cui viene utilizzato il nuovo servizio!

L'interfaccia utente è stata consegnata nel browser? Se è così, puoi fare ogni sorta di cose interessanti con sottodomini, proxy e directory virtuali per permetterti di riscrivere parti dell'interfaccia in una nuova tecnologia. Certo, è difficile. Non è possibile avere Amministratore utente che osserva tutto Bootstrappy mentre Mail Merge è un incubo aziendale grigio scuro. La tua persona UX potrebbe dover mordere la lingua fino al completamento della conversione.

Ti interessa la nuova tecnologia dei dati? Identifica una piccola parte del modello di dati che funzionerebbe bene in MongoDB o Stardog o Big Table.

Livello nella cache distribuita.

Hai un'idea.

I vantaggi di questo approccio sono legioni:

• Puoi verificare che le tue ipotesi su una riscrittura siano corrette. Se è ancora un casino, forse chiamalo prima di spendere tutti i soldi della tua azienda.
• Dimostra progressi concreti ai tuoi sponsor.
• Distribuisci il rischio nel tempo e risparmia tutto per un terrificante lancio.
• Scopri come vai. È più facile adattarsi al prossimo sviluppo, anziché eseguire un'altra riscrittura.
• Spezzare i blocchi ti costringe a pensare al design modulare.