Considerazioni prima di riscrivere un componente software da zero? [duplicare]

Non è che il codice riscritto è cattivo, è come lo fai. Tutti pensano che il loro caso sia l'eccezione.

Una grande riscrittura è come scalare una montagna. Non vuoi rimuovere la sicurezza precedente fino a quando il prossimo non è al suo posto, e fai passi piccoli e deliberati. Sembra che il tempo per farlo in sicurezza ti impedisca di raggiungere la cima, ma alla fine ci arrivi.

Scopri la parte più semplice, più piccola e più vantaggiosa che puoi refactoring, metti i test intorno, poi fallo, senza cambiando il resto del codice. Quindi ripetere il processo. A volte questo richiede un codice di hack temporaneo per collegare tra il vecchio e il nuovo codice. Le cose potrebbero temporaneamente peggiorare prima di migliorare, ma a lungo andare nella giusta direzione. L'idea è che se si fa a pezzi qualsiasi parte della riscrittura, si può tornare a uno stato buono noto senza dover tornare indietro più di un giorno di lavoro nel controllo del codice sorgente.

Penso che tu stia trascurando qualcosa - NON PUOI riscriverlo, perché hai ammesso di non avere idea di cosa stia facendo!

È bello rendersi conto che avrai bisogno di test, ma cosa testerai? Tu non sai cosa fa! Come lo test?

Prima di poter riscrivere, devi specularlo, il che significa sedersi con il codice esistente per chissà quanto tempo e esaminare ogni istruzione SQL, ogni script e assicurarti di sapere cosa sta facendo e perché lo sta facendo esso. Particolarmente importanti sono l'identificazione di strani effetti collaterali che risultano essere comportamenti previsti. Tutto pur mantenendo l'app esistente. Buona fortuna.

Se non riesci a dedicare questo tipo di tempo alle specifiche (e la maggior parte delle persone non può), allora devi sistemarle pezzo per pezzo. Al prossimo ordine di modifica, identifica la funzione che stai modificando, come funziona, scrivi i test e riscrivi quel pezzo.

Assicurati di avere solidificato il tuo team e i tuoi processi di sviluppo. Non vedo come tu possa sentirti sicuro di migliorare questa app con un test di Joel di 4. Questo progetto potrebbe usare circa 8. Potresti subire lo stesso destino che questo progetto ha fatto con la gestione non cooperativa, la scarsa pianificazione, l'inesperienza membri del team, mancanza di buone pratiche, richieste di cambiamento inattese, scadenze irragionevoli. Durante molti progetti, "la vita accade", quindi devi essere preparato.

Spero che la tua azienda stia pagando per riscrivere l'app perché è importante. Le app che sono critiche hanno solitamente bug corretti da correggere e un gran numero di richieste di modifica con programmi di consegna stretti. Non ti piace il vecchio codice perché è difficile da mantenere, quindi vuoi aumentare il tempo di correzione, aggiungere nuove funzionalità mentre stai scrivendo un nuovo codice base? Puoi risparmiare tempo a lungo termine, ma sei come un business senza flusso di cassa. Come puoi fornire le modifiche / correzioni di cui hanno bisogno in questo momento (Joel 5 - correggere i bug prima del nuovo codice - gli utenti lo chiederanno)? Hai bisogno di alcune efficienze (Joel 1,2,3,6,7 - build, controllo del codice sorgente, pianificazioni, specifiche).

Il tuo team si troverebbe in una posizione migliore per affrontare questo progetto con gli strumenti e ambiente corretti (Joel 8 (condizioni di lavoro), 9 (i migliori strumenti)). La tua azienda è pronta a sostenere questo progetto? Al di fuori del tuo gruppo, chiunque può impegnarsi a testare? (Gioele 10, 12)

Ci saranno bug (Joel 4 & 5) nel codice corrente e nella tua nuova app . Turnover del programmatore (Joel 11 - i candidati scrivono il codice durante l'intervista).

Sembra che tu sia preparato ad affrontare questo progetto. Assicurati che tutti gli altri lo siano. Potrebbe essere necessario eseguire una nave più stretta rispetto alla maggior parte delle squadre.

Se possibile, esegui modulo per modulo.

Se il sistema attuale non è "molto modulare", prova a identificare i pezzi che possono essere modularizzati e rifattili 1 alla volta, introducendo casi di test ecc.

Inizia con quello che sembra essere il modulo più semplice. Fallo bene Quindi vai al successivo.

Sembra che tu abbia una buona conoscenza di ciò che dovresti fare, quindi buona fortuna!