Rifacimento a basso impatto e pulizia del codice del codice sciatto durante l'attesa dei requisiti

Innanzitutto vorrei sottolineare che i test unitari non sostituiscono i test di integrazione. I due devono esistere fianco a fianco. Sii grato di avere test di integrazione, altrimenti uno dei tuoi piccoli refactoring potrebbe far diventare balistica una delle vacche da reddito a bassa tolleranza.

Vorrei iniziare a lavorare sugli avvisi del compilatore e sulle variabili e importazioni inutilizzate. Prendi prima una build pulita. Quindi inizia a scrivere test unitari per documentare il comportamento corrente, quindi avvia il vero refactoring.

Non riesco a vedere alcun impatto negativo. Otterrete molta comprensione profonda della base di codice, che aiuterà con i più grandi refactoring. È quasi sempre preferibile un refactoring piuttosto che una riscrittura, poiché durante il refactoring il tuo ha ancora un prodotto funzionante, mentre durante la riscrittura non lo fai. E alla fine le vendite del prodotto devono pagare il tuo stipendio.

Una volta che i requisiti stanno iniziando a venire, vorrei usare quello che chiamo l'approccio spotlight. Fai la solita cosa agile (dai priorità, poi taglia una piccola lastra per un'iterazione e lavoraci) e lascia un po 'di tempo per i miglioramenti del codice. Quindi refactoring dove lavori comunque. Nel tempo questo coprirà vaste aree della base di codice senza che tu debba mai avventurarti in aree in cui avresti difficoltà a giustificare al management il motivo per cui stai lavorando su quella parte del codice.

Scrivere i test delle unità potrebbe essere un uso più prezioso del tuo tempo: ti darà alcune informazioni sul funzionamento corrente della base di codice, e se dovessi decidere di iniziare da quello che hai invece di riscrivere tutto da zero, avrai una base solida per apportare modifiche senza correre troppi rischi. È probabile che durante la scrittura dei test unitari, si apportino modifiche alla base del codice solo per ottenere una forma testabile; quelli sono buoni, perché di solito test unitari significa anche modulare, incapsulato e per lo più indipendente dallo stato esterno. E, soprattutto, i test unitari ben scritti sono una documentazione tecnica inestimabile. Con i test unitari in atto, sarai in grado di giudicare cosa può o non può fare la base di codice corrente, piuttosto che indovinare o riscrivere le cose per sicurezza.

Risposte miste - il mio pensiero sarebbe quello di unire test e pulizia - forse 50/50? Se lavori in un'area che fa un approccio TDD - imposta i test devi sapere che l'unità e il test di integrazione sono come desiderato e quindi iniziare a ripararli. Prosegui quando il tempo lo consente.

Probabilmente significa che non farai più progressi, ma significa che avrai una base di codice ben stabile in alcune aree, e avrai una buona base di partenza.

Inizialmente, la mia reazione istintiva era "può davvero far male pulire il codice rotto?" (aka, errori del compilatore), ma poi mi sono ricordato dei momenti in cui risolvere il problema in realtà ha rotto la funzionalità in alcuni casi davvero strani perché invece di un thread che muore, ha lasciato la memoria in cattive condizioni - essenzialmente una brutta interruzione stava mascherando un errore ancora peggiore. Può letteralmente essere una scatola di Pandora di spiacevoli sorprese.

Dato che lo stai facendo in attesa di ulteriori requisiti, penso che tutto ciò che puoi per diagnosticare il caos aumenti notevolmente il tuo equilibrio a lungo termine.