Come migliorare le revisioni del codice quando le richieste pull sono grandi?

Abbiamo avuto questi problemi e porre la domanda di seguito ha funzionato bene per noi:

Il PR fa una cosa che può essere unita e può essere testata indipendentemente?

Cerchiamo di infrangere le PR da una singola responsabilità (SR). Dopo il respingimento iniziale, la gente è rimasta sorpresa nel constatare che anche qualcosa di piccolo anche se singolo può essere grande.

La SR rende davvero facile la revisione e diffonde anche la conoscenza dell'implementazione prevista.

Ciò consente anche refactives incrementali man mano che viene aggiunto altro e il tempo di risposta PR viene drasticamente ridotto!

Suggerirei di suddividerli per SR se possibile e vedere se funziona per te. Prende un po 'di pratica per farlo in quel modo.

A volte non puoi evitare grosse richieste di pull - ma puoi discernere su chi ha quale responsabilità.

Tratto le richieste pull come argomenti persuasivi. L'autore sta cercando di convincermi che il codice dovrebbe apparire e funzionare in questo modo.

Come per qualsiasi argomento, dovrebbe avere una sola chiara idea. È uno dei due:

• un refactoring,
• un'ottimizzazione,
• o nuova funzionalità.

Se non sono chiari, ci sono buone probabilità che non lo capiscano da soli. Apri il dialogo e aiutali a suddividere le loro argomentazioni nelle sue argomentazioni secondarie. Se necessario, è perfettamente a posto - anche utile per loro ricreare quei commit e offrire richieste di pull più comprensibili e dirette.

Ci saranno ancora grosse richieste di pull, ma con una discussione chiara è molto più facile vedere cosa non va bene.

Per quanto riguarda gli strumenti, dipende dalla tua organizzazione e dal tuo processo. BitBucket è uno strumento decente, che sia migliore o meno dipende da tutto, dal budget, all'hardware, ai requisiti, ai processi preesistenti, alle regole aziendali e ai vari adattamenti software che hai già realizzato per ospitare BitBucket. Vorrei iniziare esaminando la documentazione per vedere se il comportamento può essere configurato, magari buttandolo nella comunità dei plug-in (o collegandolo creando un plug-in per farlo).

Non riesaminare la richiesta pull completa, ma ogni commit. Acquisirai comunque una migliore comprensione della richiesta di pull in questo modo.¹

Se i commit sono piccoli, fare questa revisione non dovrebbe essere un problema. Segui i cambiamenti uno ad uno attraverso i commit e finisci per ottenere l'immagine completa. Ci sono degli svantaggi, come ad esempio che a volte rivedi le modifiche che verranno annullate dopo qualche commit, ma questo non dovrebbe essere un buon affare.

Se i commit sono grandi, dovresti discuterne con la persona che ha commesso tali commit. Spiegagli perché i grandi impegni sono problematici. Ascolta le argomentazioni dell'altra persona sul motivo per cui le modifiche vengono commesse raramente: potresti imparare, ad esempio, che evita di eseguire commit perché i hook pre-commit richiedono troppo tempo, nel qual caso questo problema dovrebbe essere risolto per primo.

Reviewing a pull request by commits often solves the size problems, but I don't like it since I'll frequently be looking at outdated changes.

Sì, ma questo è un problema minore e dovresti sprecare molto meno tempo a rivedere il codice che verrà annullato dopo qualche commit rispetto al tempo che hai sprecato cercando di capire perché il codice è stato cambiato durante la revisione di un singolo file.

"Frequentemente" è vago, ma se ti accorgi di passare troppo tempo a esaminare il codice che non è stato trovato nella revisione finale della richiesta di pull, puoi utilizzare due tecniche:

• Passa rapidamente a tutti i commit una volta sola, leggendo i messaggi di commit. In questo modo, quando studi un particolare commit, potresti ricordare che un messaggio di commit da qualche parte più tardi ha detto che il cambiamento che stai guardando è stato annullato.

• Avere una vista affiancata dell'ultima versione del file (anche se in molti casi, per i commit di grandi dimensioni, (1) i file potrebbero essere radicalmente diversi e (2) i file potrebbero essere rinominati o i grandi blocchi di codice possono essere spostati altrove, rendendo difficile trovare il file corrispondente).

• O chiedi ai committer di schiacciare i commit quando ha senso, o avere convenzioni specifiche per i messaggi di commit in cui un commit annulla una parte di un altro, e fai in modo che la tua recensione tenga conto di diversi commit successivi.

^{¹ Ad esempio, immagina di guardare un file in cui alcune variabili sono state rinominate. Cosa ti dice? Come dovresti riesaminare questo cambiamento? Se lo stavi verificando commit by commit, tuttavia, vedresti che un singolo commit ha rinominato la stessa variabile in venti file e il commento indica che il nome è stato modificato per utilizzare il termine commerciale corretto. Questo cambiamento ha perfettamente senso ed è possibile rivedere.}

Scopri cosa stai cercando di ottenere con le recensioni delle richieste di pull e vedi se esiste un'alternativa.

Ad esempio, potresti

• Verifica che gli standard siano seguiti
• Verifica la funzionalità è corretta
• Assicurati che più di una persona capisca il codice
• Train junior

etc etc.

Alcuni di questi potrebbero essere meglio serviti da altre cose, e anche solo comprenderne i motivi ti consente di limitare l'ambito dei tuoi assegni.

Ad esempio se sto controllando ogni riga in modo da poter suggerire e modificare il discus per l'allenamento, allora posso saltarlo su un PR di grandi dimensioni fatto dagli anziani

Se ho bisogno di capire il codice, magari accoppiare la programmazione su grandi funzionalità e limitare la revisione del codice ad un controllo standard.

Non hai bisogno di controllare tutte le cose su ogni PR finché disponi di un approccio a più livelli per il controllo della qualità