Rendere le richieste pull più facili da recensire mentre pratichi XP e refactoring

Hai scritto

When someone says "this will need a lot of testing", I show them how I got there

Quindi non potevano ottenere facilmente le informazioni "come ci si è arrivati" dai registri di commit, dovevi spiegarle a loro? Ciò mi dà l'impressione che i tuoi commit siano troppo grandi, o che i tuoi messaggi di commit debbano essere migliorati, o entrambi. Quindi consiglierei quanto segue:

• Separa i refactoring rigorosamente da modifiche che influiscono sul comportamento e li impegni singolarmente

• Evita persino di commettere più refactoring contemporaneamente, specialmente quando le aree del codice interessate si "sovrappongono".

• Assicurati che ogni refactoring che hai fatto sia menzionato nel tuo commit e concentrati sulla scrittura perché hai cambiato qualcosa.

Ad esempio, quando cambi il nome di una funzione o di una variabile membro in cui devi toccare più file, non mescolare questo con un refactoring della "funzione di estrazione". Piuttosto, compilare e confermare la ridenominazione e menzionare il tipo di ridenominazione (e forse perché l'hai fatto) nel registro. Quindi imposta la "funzione di estrazione" come un commit separato e menziona per quale motivo hai estratto la funzione. Se, ad esempio, è stato rimosso anche del codice duplicato riutilizzando la funzione appena estratta, è opportuno menzionarlo. Se questa rimozione della duplicazione interesserà molte posizioni nel tuo codice, considera di farlo in un commit separato.

In questo modo, se i revisori hanno problemi a comprendere la tua ultima richiesta di pull, possono passare attraverso il log di commit e seguire i singoli passaggi delle modifiche uno per uno.

Non so in quale altro modo rispondere a questa domanda se non per esperienza personale. Ho una circostanza simile, anche se i miei colleghi sono probabilmente meno disposti a lamentarsi delle mie richieste di pull, a causa della mia posizione nella squadra. Tuttavia, cerco di far sì che il team possa capire cosa ho fatto e perché ho rifattorizzato una cosa e ho fiducia attraverso test unitari o test di integrazione che le modifiche apportate non introducono problemi.

Ci sono tre cose che faccio, ma si riducono tutte a disciplina . Non c'è niente di meglio che disciplinare le tue abitudini di codifica.

1. Rispetta il problema assegnato . Si spera che tu abbia biglietti di emissione ben scritti che descrivono esattamente cosa deve essere fatto. È spesso allettante tuffarsi nel codice legacy per iniziare a "aggiustare" tutto ciò che tocca il tuo nuovo codice. Resisti alla tentazione e invia nuovi problemi per le correzioni che non sono strettamente necessarie per risolvere il problema su cui stai lavorando.
2. Impegna in modo significativo . Ho visto molti sviluppatori che lavorano su un problema e quindi fanno semplicemente git commit -a quando hanno finito. Se sono stati toccati molti file e le modifiche hanno richiesto diversi giorni, il singolo commit includerà molte cose e sarà difficile da valutare in una richiesta di pull. Meno frequentemente, ho visto sviluppatori che commettono ogni singolo file o pochi cambiamenti separatamente, e una richiesta pull relativamente semplice avrà dozzine di commit. La decomposizione delle attività è un'abilità chiave qui. Il modo in cui penso a come commettere correttamente è quello di descrivere a parole in una lista di proiettili quali passi prenderò per risolvere un problema. Questo dovrebbe allinearsi (più o meno) alla lista di commit che ho nella mia richiesta di pull quando ho finito. Certo, è sempre bello assicurarsi che nessun singolo commit interrompa la compilazione (compilare o testare, in base alla politica di gestione del codice sorgente del progetto), ma a volte ciò non è fattibile. Per quanto mi riguarda, ho l'obiettivo di evitare di rompere compilare su ogni singolo commit, ma il test non può passare fino a quando tutto il lavoro è fatto. Ovviamente, se segui rigorosamente TDD, i tuoi test non verranno superati prima del completamento del tuo lavoro.
3. Aumenta la copertura del test, se necessario . Non c'è sostituto per la copertura del test. Se si esegue il refactoring del codice legacy, è responsabilità dell'utente aggiungere la copertura di test appropriata, anche se in precedenza non erano presenti test equivalenti. Se sai che le tue modifiche creeranno la necessità di test di regressione da parte di qualcun altro, tale sforzo deve essere parte della discussione prima di iniziare a lavorare sul problema. Non è giusto che i tuoi colleghi modifichino il codice a cui sono abituati a comportarsi (anche se non era ben coperto) e non forniscono anche test per coprire i tuoi account e delle modifiche aggiuntive lavoro degli altri, e poi alcuni. A volte aggiungo test sul codice che non ho modificato, solo per dimostrare a me stesso che funziona e posso dipendere da esso. Questo spesso sembra un lavoro ingrato, ma salverà così tanto dolore e angoscia lungo la strada. Ciò non esclude la necessità di una copertura di regressione aggiuntiva come hai descritto, ma ti darà sicurezza in ogni momento.

Ora, se sei già un programmatore disciplinato e fai già tutte queste cose, forse i tuoi colleghi tollerano il rischio o il cambiamento è appena inferiore al tuo, o forse il team non ritiene di avere il tempo disponibile per sistemare tutti i cambiamenti. Tutte queste cose indicano la necessità di una migliore comunicazione di gruppo e una migliore comprensione condivisa degli impatti prima che il lavoro inizi sui problemi.

Buona fortuna!

Una cosa che potrebbe aiutare sarebbe quella di elencare i refactories che hai usato nel messaggio di commit.