Non si tratta di efficienza, si tratta di mantenere un sistema funzionante. Mi piace paragonare il refactoring all'arrampicata in montagna. Non rimuovi mai la sicurezza precedente fino a quando non è in atto il successivo. Sì, è laborioso. Sì, sembra che ci voglia più tempo, ma le conseguenze di eventuali errori sono molto più piccole.

Inoltre, in genere vuoi pensare al refactoring in termini di sezioni verticali. Fai il minimo necessario per migliorare una piccola parte in tutti i livelli. Ad esempio, invece di affrontare l'intero database in una volta, scegli una tabella o anche un campo e passa attraverso tutti e sei i passaggi, quindi ripeti per un'altra tabella. Imparerai le cose ogni volta che ciò renderà le cose più facili nei turni successivi, quindi fai in modo che il tuo feedback sia il più breve possibile.

Come effetto collaterale, i cicli brevi facilitano l'acquisto dalla direzione. "Ricorda quanto i miei cambiamenti hanno accelerato la pagina delle fatture? Voglio fare la stessa cosa per il carrello degli acquisti, il che dovrebbe anche rendere questa nuova funzione più veloce da aggiungere e più robusta."

Lo scenario di cui parli (e Funzionante in modo efficace con il codice legacy ) probabilmente non ti consente di seguire un piano a lungo termine. È bello sapere dove vorresti arrivare, ma in genere in un sistema live la maggior parte del refactoring avviene a piccoli passi al servizio di una particolare correzione di bug o di una nuova funzionalità.

L'ordine di refactoring è quindi determinato in modo significativo da quali esigenze aziendali hanno una priorità sufficientemente elevata su cui lavorare. Tuttavia, per ogni storia su cui lavori, dovrai decidere quanta tecnica di refactoring debba assumere e come affrontarla, e potresti anche essere in grado di eliminare anche alcuni refactoring non direttamente (business).

Quando hai una scelta darebbe priorità (ma non assoluta) alla priorità di non rompere le cose, e seconda priorità a ottenere pezzi del sistema sotto test. Entrambi hanno una priorità più alta rispetto alla progettazione pulita, poiché è possibile ripulire il progetto in modo molto più efficace se il sistema è in fase di test.

Per il tuo esempio specifico è difficile prevedere in anticipo quale ordine si dovrebbe finire con il refactoring. La mia ipotesi è che perlomeno dipenda dall'interfaccia utente - una volta che l'interfaccia utente si è occupata del livello intermedio tramite un'API più ragionevole, probabilmente si separerebbe ulteriormente la logica aziendale dal database in modo da poter effettuare il refactoring del DB e migrare i dati. Si spera che il modello di dati modificato non sia visibile all'interfaccia utente e non richiederebbe modifiche all'interfaccia utente.

Ma probabilmente questo processo si sta verificando in qualche modo in parallelo con diverse parti dell'applicazione, e in alcuni casi potrebbe finire in un ordine diverso.

Il refactoring di un sistema live è in genere necessariamente un processo opportunistico e dal basso verso l'alto per sapere in anticipo quale sarà l'ordine.