Come nota a margine: cerca un nuovo lavoro. Questo non starebbe meglio.
Gli obiettivi del codice che stai esaminando sono:
Per spedire una funzione, che dovrebbe funzionare in base ai requisiti.
Ridurre la crescita del debito tecnico.
Il primo obiettivo viene esaminato verificando che l'unità, l'integrazione, il sistema e i test funzionali siano qui, che siano pertinenti e che coprano tutte le situazioni che devono essere testate. Devi anche verificare le convinzioni che l'autore originale potrebbe avere riguardo al linguaggio di programmazione, che potrebbe portare a bug sottili o al codice che finge di fare qualcosa di diverso da ciò che effettivamente fa.
Il secondo obiettivo è quello su cui la tua domanda è focalizzata. Da un lato, il nuovo codice non dovrebbe aumentare il debito tecnico. D'altro canto, l'ambito della revisione è il codice stesso, ma nel contesto dell'intera base di codice. Da lì, tu, come revisore, puoi aspettarti due approcci dall'autore originale:
Il codice esterno non è colpa mia. Ho appena implementato la funzione e non mi interessa l'intera base di codice.
In questa prospettiva, il codice copierà i difetti della base di codice, e quindi inevitabilmente aumenterà il debito tecnico: più cattivo codice è sempre peggio.
Sebbene questo sia un valido approccio a breve termine, a lungo termine comporterebbe ritardi crescenti e bassa produttività, e alla fine porterebbe a un processo di sviluppo così costoso e rischioso che il prodotto smetterebbe di evolversi.
Scrivere un nuovo codice è un'opportunità per riformattare quello precedente.
In questa prospettiva, l'effetto dei difetti del codice legacy su quello nuovo potrebbe essere limitato. Inoltre, il debito tecnico potrebbe essere ridotto, o almeno non aumentato proporzionalmente alla crescita del codice.
Sebbene si tratti di un valido approccio a lungo termine, presenta rischi a breve termine. Il principale è che, a breve termine, a volte ci vorrebbe più tempo per spedire la funzionalità specifica. Un altro aspetto importante è che se il codice legacy non è testato, il refactoring presenta un rischio enorme di introdurre regressioni.
A seconda della prospettiva che si desidera incoraggiare, si può essere propensi a consigliare ai revisori di rifattorizzare di più o meno. In ogni caso, non aspettarti un pezzo di codice impeccabile e pulito con una bella architettura e design all'interno di una base di codice scadente. Ciò che non dovresti incoraggiare è il comportamento in cui uno sviluppatore esperto che deve lavorare su una base di codice schifosa cerca di fare bene la sua parte . Invece di semplificare le cose, le rende solo più complicate di prima. Ora, invece di un cattivo codice uniforme, hai una parte con motivi di progettazione, un'altra parte con un codice pulito e chiaro, un'altra parte che è stata ampiamente riformulata nel tempo e nessuna unità di sorta.
Immagina, ad esempio, di scoprire una base di codice legacy di un sito Web di medie dimensioni. Sei sorpreso dalla mancanza di una normale struttura e dal fatto che la registrazione, una volta eseguita, viene eseguita aggiungendo manualmente le cose a un file di testo, invece di utilizzare un framework di registrazione. Decidi per la nuova funzionalità di utilizzare MVC e un framework di registrazione.
Il tuo collega sta implementando un'altra funzione ed è molto sorpreso dalla mancanza di un ORM in cui si farebbe una dimensione perfetta. Quindi inizia a usare un ORM.
Né tu, né il tuo collega siete in grado di esaminare centinaia di migliaia di righe di codice per utilizzare MVC, un framework di registrazione o un ORM ovunque. In realtà, richiederebbe mesi di lavoro: immagina di introdurre MVC; quanto tempo ci vorrebbe? O che dire di un ORM in situazioni in cui le query SQL sono state generate caoticamente attraverso la concatenazione (con posizioni occasionali per SQL Injection) all'interno del codice che nessuno poteva capire?
Pensi di aver fatto un ottimo lavoro, ma ora un nuovo sviluppatore che si unisce al progetto deve affrontare molta più complessità rispetto a prima:
Il vecchio modo di trattare le richieste,
The MVC way,
Il vecchio meccanismo di registrazione,
Il framework di registrazione,
L'accesso diretto al database con query SQL integrate al volo,
L'ORM.
In un progetto su cui stavo lavorando, c'erano quattro (!) Framework di registrazione usati fianco a fianco (più registrazione manuale). Il motivo è che ogni volta che qualcuno voleva registrare cose non c'era un approccio comune per farlo, quindi invece di imparare un nuovo framework (che in tutti i casi veniva usato solo nel 5% della base di codice), si aggiungeva semplicemente un altro lo sa già. Immagina il casino.
Un approccio migliore potrebbe essere il refactoring della base di codice un passo alla volta. Prendendo ancora una volta l'esempio della registrazione, il refactoring consisterebbe nei seguenti piccoli passi:
Trova tutti i luoghi in cui viene eseguita la registrazione legacy (ovvero quando si accede direttamente al file di registro) e assicurarsi che tutti chiamino gli stessi metodi.
Sposta questo codice in una libreria dedicata, se applicabile. Non desidero registrare la logica di archiviazione nella mia classe del carrello.
Modificare, se necessario, l'interfaccia dei metodi di registrazione. Ad esempio, possiamo aggiungere un livello che indica se il messaggio è informale o è un avviso o un errore.
Utilizzare i metodi appena refactored nella nuova funzionalità.
Migrare al framework di registrazione: l'unico codice interessato è il codice all'interno della libreria dedicata.