Consigli sull'approccio a un riarrangiamento / refactoring significativo?

Question

Consigli sull'approccio a un riarrangiamento / refactoring significativo?

#1 da (10 voti)
#2 da (3 voti)

1

Sto lavorando su un'applicazione (progetto per hobby, programmatore solista, dimensioni medio-piccole) e di recente ho ridisegnato una parte significativa di esso. Il programma funziona già nel suo stato attuale, ma ho deciso di reimplementare le cose per migliorare il design OO.

Sto per implementare questo nuovo design rifattorizzando gran parte dell'applicazione. Il fatto è che non sono sicuro da dove cominciare. Ovviamente, per la natura di un riarrangiamento, nel momento in cui modifichi una parte del programma, molte altre parti (almeno temporaneamente) si spezzano. Quindi è un po '"spaventoso" riorganizzare qualcosa in un software che funziona già.

Chiedo consigli o alcune linee guida generali: come devo affrontare un refactoring significativo? Quando ti avvicini riordinando grandi parti della tua applicazione, da dove inizi?

Tieni presente che sono interessato solo a riorganizzare la struttura di alto livello dell'app. Non ho intenzione di riscrivere gli algoritmi locali.

object-oriented design rewrite

posta Aviv Cohn 21.08.2014 - 23:20

fonte

2 risposte

10

Trascorri la maggior parte del tuo tempo scrivendo test completi e dettagliati su unità e integrazione. Sono il pezzo che ti dirà se i cambiamenti stanno rompendo altri pezzi.

Quindi modifica i pezzi in un piccolo passo il più possibile ed esegui tutti i test precedenti, oltre a test manuali, tra ogni passaggio.

Per le modifiche apportate, utilizza un sistema di controllo della versione distribuito come git in modo da poter applicare e modificare i rollback.

risposta data 21.08.2014 - 23:47

fonte

Leggi altre domande sui tag object-oriented design rewrite

In alternativa alla goto-statement in questo caso? [duplicare] L'override di un metodo influisce sulla chiamata di una superclasse?

score 3 · Accepted Answer

Riscrivere un'applicazione completa solo perché non ti piace il codice di solito non è una buona idea. Il refactoring di solito per il refactoring di solito non risolve alcun problema, ma ne introduce diversi nuovi.

Quando hai imparato qualcosa di nuovo che migliorerebbe totalmente il design della tua applicazione precedente, resisti all'impulso di riscriverlo. Ci sarà sempre un prossimo progetto in cui puoi applicare le tue conoscenze.

L'unica situazione in cui il refactoring su larga scala ha senso è quando si tenta di aggiungere una nuova funzionalità e ci si rende conto che l'architettura corrente non consente di farlo in modo elegante. Quindi potresti considerare di fare le necessarie riscritture mentre sviluppi quella caratteristica. Basta non dimenticare il tuo obiettivo: ottenere quella funzionalità per il lavoro.