Che cosa fai se trovi che una riscrittura impiega troppo tempo?

Sembra che tu stia soffrendo di Second System Effect .

Suggerirei di tornare al vecchio sistema. Quindi scegliere tra il refactoring (che non sono un grande fan di quanti qui intorno) o provare a scrivere una sostituzione minima utilizzabile per il meno possibile della funzionalità del sistema originale. Ma state alla larga da "Ecco il mio grande progetto su come fare tutto bene!" Perché in questo modo ci sono draghi che hanno bruciato molti sviluppatori incauti.

I casi in cui è necessario riscrivere ogni riga di codice sono rari, specialmente per progetti di grandi dimensioni. In che modo il codice può essere sbagliato nella riga di codice ogni , dopo tutto? Cosa c'è di sbagliato nella seguente riga, ad esempio?

int a = b + c;

Ciò che è importante, d'altra parte, è fare il refactoring regolarmente.

• Alcune modifiche al refactoring possono essere piccole (cambia il nome della variabile locale pi in productId , perché, beh, pi è troppo fuorviante).

• Altre modifiche potrebbero invece costringere a modificare l'intera struttura della tua applicazione e influenzare migliaia di righe di codice.

La cosa più importante in questo caso è avere una solida ragione per fare il refactoring. Spendere migliaia di dollari di un cliente che refactoring un codice che non sarà nemmeno usato in pochi mesi non è una buona idea; al contrario, spendere migliaia di dollari refactoring un codice che è quasi impossibile da modificare e per il quale, ogni cambiamento ha un costo estremamente elevato, non è così male se il codice è destinato ad essere utilizzato per anni.

In tutti i casi, puoi evitare l'intera riscrittura effettuando piccoli refactoring. Per una settimana devi refactoring una parte di un codice, lasciando altre parti per ulteriori refactoring. Mesi dopo, inizierai a refactoring un'altra parte del tuo codice, ecc.

Due cose:

1. Si dice che solo il 20% di tutte le funzionalità di un sistema viene effettivamente utilizzato, quindi se si desidera abbreviare il tempo di riscrittura, considerare di lavorare solo su quelle del 20% e rilasciare quando sono terminate. Lavora in modo incrementale.
2. Dovresti usare le tue conoscenze del vecchio sistema e rendere il nuovo sistema migliore, più mirato e facile da usare. Semplicemente imitando il vecchio sistema pezzo per pezzo, in realtà non dai ai tuoi utenti alcun valore.

Questa è una piccola risposta, ma se ti trovi troppo conflittuale, questo può essere di per sé il tuo peggior nemico. Penso che ci sia un merito in entrambi i punti di vista. Cerca i tuoi sentimenti su di esso e impegnarsi ad esso, e seguire attraverso. Alla fine, sarà se hai completato o meno. Dubito che qualcuno ti perseguiterà se consegnerai.

Nella mia esperienza, quando hai un progetto che è semplicemente sbagliato dal basso verso l'alto, la cosa migliore da fare è dare fuoco a tutto e correre un po 'in mutande, prima di sederti e non solo fare una riscrittura, ma una completa riscrittura bottom-up, clean-room dell'intero progetto.

Alcuni progetti possono essere sottoposti a refactoring in invio, certo, ma alcuni ...

Non così tanto.

Soprattutto nei vecchi progetti; iniziare con una lavagna pulita utilizzando strumenti moderni è in genere più veloce e meno soggetto a errori rispetto al tentativo di eseguire una riscrittura riga per riga; almeno nella mia esperienza.