Comment améliorer les révisions de code lorsque les demandes d'extraction sont importantes?

Avis de non-responsabilité: il existe des questions similaires, mais je n'en ai trouvé aucune qui concerne spécifiquement les problèmes auxquels vous êtes confronté lors de l'examen d'une grande demande de tirage.

Problème

Je pense que mes révisions de code pourraient être faites d'une meilleure façon. Je parle en particulier des révisions de code importantes avec de nombreux changements dans plus de 20 fichiers.

Il est assez simple de détecter les problèmes de code local évidents. Comprendre si le code répond aux critères commerciaux est une autre histoire.

J'ai du mal à suivre le processus de réflexion de l'auteur du code. C'est assez difficile lorsque les modifications sont nombreuses et réparties sur plusieurs fichiers. J'essaie de me concentrer sur les groupes de fichiers liés à un élément particulier des modifications. Passez ensuite en revue les groupes un par un. Malheureusement, l'outil que j'utilise (Atlassian Bitbucket) n'est pas très utile. Chaque fois que je visite un fichier, il est marqué comme vu, même s'il s'avère souvent ne pas être lié à l'élément de changement actuellement examiné. Sans oublier que certains fichiers doivent être visités plusieurs fois et leurs modifications revues pièce par pièce. De plus, revenir aux fichiers pertinents lorsque vous suivez un mauvais chemin n'est pas facile.

Solutions possibles et pourquoi elles ne fonctionnent pas pour moi

L'examen d'une demande de tirage par des validations résout souvent les problèmes de taille, mais je n'aime pas cela, car je vais souvent examiner des modifications obsolètes.

Bien sûr, la création de demandes d'extraction plus petites semble être un remède, mais c'est ce que c'est, parfois vous obtenez une grande demande d'extraction et elle doit être examinée.

Vous pouvez également ignorer l'aspect logique du code dans son ensemble, mais cela semble assez risqué, en particulier lorsque le code provient d'un programmeur inexpérimenté.

Utiliser un meilleur outil pourrait être utile, mais je n'en ai pas trouvé.

Des questions

• Avez-vous des problèmes similaires avec vos révisions de code? Comment les affrontez-vous?
• Vous avez peut-être de meilleurs outils?

Nous avons eu ces problèmes et poser la question ci-dessous a bien fonctionné pour nous:

Le RP fait-il une chose qui peut être fusionnée et testée indépendamment?

Nous essayons de briser les RP par responsabilité unique (SR). Après le repoussage initial, les gens ont été surpris de constater que même quelque chose de petit, bien que simple, pouvait être grand.

Le SR facilite vraiment l'examen et diffuse également les connaissances sur la mise en œuvre attendue.

Cela permet également des refacteurs incrémentaux à mesure que plus est ajouté et que le délai d'exécution des relations publiques est considérablement réduit!

Je suggère de les séparer par SR si possible et de voir si cela fonctionne pour vous. Prend un peu de pratique pour le faire de cette façon.

Parfois, vous ne pouvez pas éviter de grandes demandes de tirage - mais vous pouvez discerner qui a quelle responsabilité.

Je traite les demandes de tirage comme des arguments convaincants. L'auteur essaie de me convaincre que le code devrait ressembler et fonctionner de cette façon.

Comme pour tout argument, il doit avoir une seule idée claire. C'est soit:

• un refactor,
• une optimisation,
• ou de nouvelles fonctionnalités.

S'ils ne sont pas clairs, il y a de fortes chances qu'ils ne le comprennent pas eux-mêmes. Ouvrez le dialogue et aidez-les à décomposer leur argument en ses sous-arguments. Si besoin est, c'est tout à fait correct - même bénéfique pour eux de recréer ces commits et d'offrir des demandes de tirage plus compréhensibles et directes.

Il y aura toujours de grandes demandes d'extraction, mais avec un argument clair, il est beaucoup plus facile de voir ce qui ne convient pas.

Quant à l'outillage, il dépend de votre organisation et de votre processus. BitBucket est un outil décent, qu'il soit meilleur ou non dépend de tout, de votre budget, matériel, exigences, en passant par vos processus préexistants, règles métier et diverses adaptations logicielles que vous avez déjà apportées pour accueillir BitBucket. Je commencerais par parcourir la documentation pour voir si le comportement peut être configuré, peut-être à lancer à la communauté des plugins (ou à le rejoindre en créant un plugin pour le faire).

N'examinez pas la demande d'extraction complète, mais chaque validation. Vous obtiendrez de toute façon une meilleure compréhension de la demande d'extraction en procédant de cette façon.¹

Si les commits sont petits, cette révision ne devrait pas être un problème. Vous suivez les modifications une par une à travers les validations et vous obtenez l'image complète. Il y a des inconvénients, tels que vous passerez parfois en revue les modifications qui seront annulées quelques commits plus tard, mais cela ne devrait pas être beaucoup.

Si les commits sont importants, vous devez en discuter avec la personne qui a effectué ces commits. Expliquez-lui pourquoi les grands commits sont problématiques. Écoutez les arguments de l'autre personne sur les raisons pour lesquelles il commet des changements rarement: vous pouvez apprendre, par exemple, qu'il évite de faire des commits parce que les hooks de pré-validation prennent trop de temps, auquel cas ce problème doit être résolu en premier.

L'examen d'une demande de tirage par des validations résout souvent les problèmes de taille, mais je n'aime pas cela, car je vais souvent examiner des modifications obsolètes.

Vous le faites, mais c'est un problème mineur, et vous devriez perdre beaucoup moins de temps à réviser le code qui sera annulé quelques commits plus tard que le temps que vous perdez à essayer de comprendre pourquoi le code a été modifié lors de la révision d'un seul fichier.

«Fréquemment» est vague, mais si vous passez trop de temps à réviser du code qui n'a pas trouvé le chemin de la révision finale de la demande d'extraction, vous pouvez utiliser deux techniques:

• Parcourez rapidement toutes les validations une seule fois, en lisant simplement les messages de validation. De cette façon, lorsque vous étudiez un commit particulier, vous vous souviendrez peut-être qu'un message de commit quelque part plus tard indique que le changement que vous regardez a été annulé.

• Avoir une vue côte à côte de la dernière version du fichier (bien que dans de nombreux cas, pour les gros commits, (1) les fichiers puissent être radicalement différents et (2) les fichiers peuvent être renommés ou les gros blocs de code peuvent être déplacé ailleurs, ce qui rend difficile la recherche du fichier correspondant).

• Soit demander aux validateurs de supprimer les validations lorsque cela a du sens, soit avoir des conventions de message de validation spécifiques où une validation annule une partie d'une autre, et faire votre examen en tenant compte de plusieurs validations suivantes.

^{¹ Par exemple, imaginez que vous regardez un fichier dans lequel une variable a été renommée. Que faut-il vous dire? Comment devriez-vous revoir ce changement? Si vous l'examiniez, commit par commit, cependant, vous verriez qu'un seul commit renommerait la même variable dans vingt fichiers, et le commentaire indique que le nom a été changé afin d'utiliser le terme commercial approprié. Ce changement est parfaitement logique et peut être révisé.}

Déterminez ce que vous essayez de réaliser en examinant les demandes d'extraction et voyez s'il existe une alternative.

Par exemple, vous voudrez peut-être

• Veiller au respect des normes
• Vérifier que la fonctionnalité est correcte
• Assurez-vous que plusieurs personnes comprennent le code
• Former les juniors

etc.

Certains d'entre eux pourraient être mieux servis par d'autres choses, et même simplement comprendre les raisons vous permet de limiter la portée de vos contrôles.

Par exemple, si je vérifie chaque ligne afin que je puisse suggérer et discuter des changements pour la formation, je peux ignorer cela sur un grand PR effectué par des personnes âgées

Si j'ai besoin de comprendre le code, peut-être faire une programmation par paires sur de grandes fonctionnalités et limiter la révision du code à une vérification des normes.

Vous n'avez pas besoin de vérifier toutes les choses sur chaque PR tant que vous avez une approche en couches de l'AQ