Il conseguente e efficiente rifattore nemico delle recensioni di codice in un contesto di codice legacy?

Per la richiesta pull è necessario fornire già un codice pulito. Dove durante la revisione altri occhi possono scoprire alcuni "piccoli" miglioramenti:

• nomi di metodi / classi
• metodi di estrazione
• ecc.

Se ogni richiesta pull richiede una quantità "grande" di refactoring, allora stai facendo qualcosa di sbagliato.

In TDD l'attività verrà eseguita solo quando si superano tutte e tre le fasi

• scrivi test fallito (rosso)
• scrivi il codice di produzione per passare il test (verde)
• refactor - questo deve essere fatto prima di poter effettuare il commit delle modifiche

Se devi refactoring costantemente, significa solo che il codice è in uno stato che necessita di refactoring, e nient'altro. Può succedere usando qualsiasi tipo di sviluppo. In generale, è una buona cosa se il codice ha bisogno di meno refactoring nel tempo: significa che il codice funziona come necessario ed è ben progettato. Questo dovrebbe essere un obiettivo, che è in linea con le modifiche minime necessarie per le revisioni del codice.

Suggerisco di evitare le revisioni di codifica finché il codice precedente non viene ripulito. Un'altra opzione è quella di rallentare il refactoring, tenendo a bada fino a quando un progetto è finalizzato, quindi fare un po 'di pulizia, commit e ripetizione. Prova a rifattorizzare ogni cosa una volta (cioè con un'attenta riflessione), e commetti dopo ogni refactoring.

TDD rende le revisioni più semplici perché i casi di test rendono più ovvio il funzionamento del codice. Una suite di test ben progettata aiuta anche a darti la certezza che il set di modifiche non sta introducendo una regressione nel resto della base di codice. Ciò consente al revisore di concentrarsi sull'eventualità che nel codice manchino casi edge ovvi o che non seguano le buone pratiche & norme.

Sembra che tu abbia l'impressione che TDD porti a un costante refactoring. Questo non è il caso. Mentre TDD può renderlo più facile per rifattorizzare il tuo codebase e farlo senza introdurre nuovi bug, il refactoring non è un requisito.

Mentre è normale scrivere iterativamente test & scrivere codice, modificando il codice in modo che corrisponda ai requisiti per i nuovi test che possono portare a grandi cambiamenti nelle prime fasi di sviluppo, questo non significa che gli sviluppatori debbano scrivere codice dopo che ogni test è stato completato. I commit dovrebbero comunque mantenere la granularità di una funzionalità completata o di una correzione dei bug.

Come menziona @Sean, il refactoring dovrebbe essere separato dalle aggiunte alle funzionalità per mantenere le cose veramente pulite.

Penso che sia utile rivedere il refactoring in quanto è quello di rivedere le aggiunte delle funzionalità.

Ogni dato refactoring deve essere spiegabile, se è sufficientemente semplice, quindi in termini di piccoli passaggi di refactoring, ma soprattutto se piccoli o grandi, in termini di astrazione applicabile al dominio che viene fornita.

Una buona astrazione opera in termini di concetti e comportamenti appropriati per il consumatore che lavorano insieme per supportare gli scenari di utilizzo del consumatore.

In un'astrazione che non prevede più nuovi scenari di utilizzo, a volte l'incompletezza è costituita dall'aggiunta di codice al consumatore che spesso conosce troppo i dettagli di implementazione dell'astrazione e deve raggiungere un livello inferiore per compongono l'incompletezza. Questo crea debito tecnico diffondendo le responsabilità tra un fornitore e il suo consumatore.

Questa situazione indica il refactoring per creare un'astrazione migliorata. Un simile refactoring può aumentare un insieme esistente di concetti e comportamenti, o può sostituire le astrazioni esistenti con una nuova serie di concetti e comportamenti più appropriati e più appropriati per il dominio.

Quando facciamo il refactoring, dovrebbe essere spiegabile: la nuova astrazione incorpora un'altra capacità o un altro concetto con capacità, o forse è un insieme completamente nuovo di concetti più semplici o più utili & comportamenti.

In entrambi i casi, dovrebbe rendere le cose più facili per il consumatore, quindi il livello successivo può "stare sulle spalle" dell'astrazione refactored invece di aggirarla.

In alcuni casi, tuttavia, l'onere di implementazione per una determinata astrazione è troppo alto (non può essere fornito senza gravi compromessi) e in quei casi l'astrazione dovrebbe fornire qualcosa di più basso, semplificando l'implementazione e presentandola al consumatore in un modo diverso.

Il refactoring riguarda la negoziazione dei confini delle nostre astrazioni e, questi aggiustamenti nei limiti dovrebbero essere spiegabili a quelli che revisionano il codice.

Trovo che mantenere il refactoring in commit separati da altre modifiche possa renderlo più semplice. Mi piace anche eseguire un refactoring in un commit e dire quale sia il refactoring nel messaggio di commit, ad es. "Extract Method getAThing () da foo.php"

Anche l'utilizzo dei nomi dei refactoring del catalogo di refactoring di Fowler è di aiuto.