Come rendere migliori le revisioni del codice quando le richieste pull sono grandi?

Disclaimer: ci sono alcune domande simili, ma non ho trovato nessuna che tocchi specificamente i problemi che affronti durante la revisione di una grande richiesta pull.

Problema

Ritengo che le mie revisioni del codice potrebbero essere eseguite in modo migliore. Sto parlando in particolare di recensioni di codici di grandi dimensioni con molte modifiche in oltre 20 file.

È abbastanza semplice rilevare ovvi problemi con il codice locale. Capire se il codice soddisfa i criteri aziendali è comunque una storia diversa.

Ho dei problemi a seguire il processo di pensiero dell'autore del codice. È piuttosto difficile quando le modifiche sono numerose e distribuite su più file. Cerco di concentrarmi sui gruppi di file relativi a una particolare modifica. Quindi rivedi i gruppi uno per uno. Purtroppo lo strumento che utilizzo (Atlassian Bitbucket) non è molto utile. Ogni volta che visito un file, questo viene contrassegnato come visto, anche se spesso risulta non essere correlato alla modifica attualmente esaminata. Per non parlare del fatto che alcuni file dovrebbero essere visitati più volte e le loro modifiche sono state riviste pezzo per pezzo. Anche tornare ai file pertinenti quando segui un percorso errato non è facile.

Possibili soluzioni e perché non funzionano per me

Revisionare una richiesta pull da commit spesso risolve i problemi di dimensione, ma non mi piace poiché vedrò frequentemente modifiche obsolete.

Naturalmente, la creazione di richieste pull più piccole sembra un rimedio, ma è quello che è, a volte si ottiene una grande richiesta pull e deve essere rivista.

Puoi anche ignorare l'aspetto logico del codice nel suo insieme, ma sembra piuttosto rischioso, in particolare quando il codice proviene da un programmatore inesperto.

L'uso di uno strumento migliore potrebbe essere utile, ma non l'ho trovato.

Domande

• Hai problemi simili con le tue recensioni di codice? Come li affrontate?
• Forse hai strumenti migliori?

Abbiamo avuto questi problemi e ponendo la seguente domanda ha funzionato bene per noi:

Il PR fa una cosa che può essere unita e può essere testata in modo indipendente?

Cerchiamo di violare i PR per singola responsabilità (SR). Dopo l'iniziale respingimento, la gente è stata sorpresa di scoprire che anche qualcosa di piccolo, anche se singolo, può essere grande.

L'SR semplifica la revisione e diffonde anche la conoscenza dell'implementazione prevista.

Ciò consente anche di ottenere rifrattori incrementali man mano che ne vengono aggiunti altri e il tempo di consegna delle PR è drasticamente ridotto!

Suggerirei di separarli da SR, se possibile, e vedere se funziona per te. Prende un po 'di pratica per farlo in questo modo.

A volte non puoi evitare richieste di pull di grandi dimensioni, ma puoi essere esigente su chi ha quale responsabilità.

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

Come per ogni argomento, dovrebbe avere un'unica idea chiara. È anche:

• un refattore,
• un'ottimizzazione,
• o nuove funzionalità.

Se non sono chiari, allora ci sono buone possibilità che non lo capiscano da soli. Apri il dialogo e aiutali a suddividere la loro argomentazione nei suoi argomenti secondari. Se necessario, va benissimo - anche vantaggioso per loro ricreare tali impegni e offrire richieste pull più comprensibili e dirette.

Ci saranno ancora grandi richieste pull, ma con un chiaro argomento è molto più facile vedere cosa non va bene.

Per quanto riguarda gli strumenti, dipende dalla tua organizzazione e processo. BitBucket è uno strumento decente, che sia migliore o meno dipende da tutto, dal budget, all'hardware, ai requisiti, fino ai processi preesistenti, alle regole aziendali e ai vari adattamenti software che hai già fatto per adattarsi a BitBucket. Inizierei guardando la documentazione per vedere se il comportamento può essere configurato, magari buttandolo nella comunità dei plugin (o unendomi a esso creando un plugin per farlo).

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

Se i commit sono piccoli, fare tale revisione non dovrebbe essere un problema. Segui i cambiamenti uno per uno attraverso gli commit e finisci per ottenere il quadro completo. Ci sono degli svantaggi, come il fatto che a volte rivedrai le modifiche che verranno annullate qualche commit in seguito, ma questo non dovrebbe essere molto.

Se i commit sono grandi, dovresti discuterne con la persona che li ha commessi. Spiegagli perché i grandi impegni sono problematici. Ascolta le argomentazioni dell'altra persona sul motivo per cui commette cambiamenti raramente: potresti imparare, ad esempio, che evita di fare commit perché gli hook pre-commit impiegano troppo tempo, nel qual caso questo problema dovrebbe essere risolto per primo.

Revisionare una richiesta pull da commit spesso risolve i problemi di dimensione, ma non mi piace poiché vedrò frequentemente modifiche obsolete.

Sì, ma questo è un problema minore e dovresti perdere molto meno tempo a rivedere il codice che verrà annullato qualche commit più tardi rispetto al tempo che sprechi cercando di capire perché il codice è stato modificato durante la revisione di un singolo file.

"Frequentemente" è vago, ma se ti ritrovi a passare troppo tempo a rivedere il codice che non ha trovato la strada per la revisione finale della richiesta pull, puoi usare due tecniche:

• Passa rapidamente attraverso tutti i commit una volta, semplicemente leggendo i messaggi di commit. In questo modo, quando studi uno specifico commit, potresti ricordare che un messaggio di commit da qualche parte in seguito ha detto che il cambiamento che stai osservando è stato ripristinato.

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

• O chiedi ai committer di eliminare i commit quando ha senso, oppure di avere convenzioni specifiche per i messaggi di commit in cui un commit annulla una parte di un'altra e fai la tua recensione tenendo conto di numerosi commit successivi.

^{¹ Ad esempio, immagina di guardare un file in cui una variabile è stata rinominata. Che cosa ti dice? Come dovresti rivedere questa modifica? Se lo stavi esaminando con commit per 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 appropriato. Questa modifica ha perfettamente senso ed è possibile rivederla.}

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

Ad esempio potresti volerlo

• Garantire il rispetto degli standard
• Verifica che la funzionalità sia corretta
• Assicurati che più di una persona capisca il codice
• Allenati per ragazzi

ecc ecc.

Alcuni di questi potrebbero essere meglio serviti da altre cose, e anche solo la comprensione dei motivi consente di limitare l'ambito dei controlli.

Ad esempio, se sto controllando ogni riga in modo da poter suggerire e discusare le modifiche per l'allenamento, allora posso saltare questo su un grande PR fatto dagli anziani

Se ho bisogno di capire il codice, magari abbina la programmazione a funzionalità di grandi dimensioni e limita la revisione del codice a un controllo standard.

Non è necessario controllare tutto su ogni PR purché si disponga di un approccio a più livelli al QA