Discussion :

[Mensur Durakovic]

Revue de code : un guide en 5 étapes pour que vos collègues vous détestent, par Mensur Durakovic

Lorsqu'elles sont effectuées correctement, les revues de code peuvent être un excellent moyen de prévenir les bogues, d'améliorer la qualité du code et de diffuser les connaissances commerciales et techniques au sein de l'équipe de développement.

La revue de code est une compétence qui prend du temps à apprendre des deux points de vue, la revue du code et la création d'un code révisable.

Cependant, les révisions de code peuvent être un casse-tête pour les réviseurs, un obstacle à la livraison et une excellente source de perte de temps lorsqu'elles ne sont pas effectuées correctement.

Si vous voulez que vos collègues vous détestent, assurez-vous de suivre les étapes suivantes.

1. Demander des modifications qui n'auront aucun effet

Pour réussir cette étape, vous devez d'abord apprendre le guide de style de code de votre entreprise.

Cela vous permettra de commencer à demander des changements de style de code qui ne sont pas explicitement mentionnés dans le guide de style.

Si votre entreprise n'a pas de guide de style de code, c'est encore mieux car cela vous permet de grinder encore plus vos collègues.

Par exemple, si votre collègue nomme une variable, une fonction ou une classe de manière trop détaillée et verbeuse, laissez un commentaire lui demandant de changer le nom pour quelque chose de moins verbeux.

Son code est-il trop élégant ?

Veillez à gâcher leur code autant qu'ils l'ont fait sur le vôtre.

Dites quelque chose sur le fait de faciliter la vie des développeurs juniors, de leur faire écrire des commentaires insignifiants ou, mieux encore, de refactoriser leur code.

Pourquoi les variables ne sont-elles pas déclarées par ordre alphabétique ?

Ce n'est pas une option. Apportez une modification !

Y a-t-il une ligne vide supplémentaire ?

Demandez une modification immédiatement pour qu'ils soient obligés de la faire !

S'il vous plaît, ne laissez pas de commentaires comme celui-ci :

Je propose que nous utilisions Y au lieu de X pour obtenir une solution plus courte, plus élégante et plus concise.

C'est trop gentil et vous donnez l'impression d'être trop gentil. Assurez-vous que votre commentaire de code est passif-agressif. Par exemple :

C'est complètement incorrect ; pourquoi ne pas utiliser X au lieu de Y ?

S'il y a deux façons de faire quelque chose, insistez pour que le code soit modifié à votre façon.

Ne vous laissez pas influencer par des arguments tels que les inconvénients de votre approche ou les avantages de la leur.

Vous devez participer à un fil de discussion de 10 commentaires dans lequel vous expliquez pourquoi cela devrait être changé.


2. Retarder la revue de code

Lorsqu'une demande de fusion est créée, vous devez vous concentrer sur la recherche rapide de quelque chose de "nauséabond" dans le code, afin de pouvoir laisser un commentaire.

La partie la plus importante est maintenant terminée. Leur demande de fusion ne sera pas fusionnée tout de suite.

S'ils sont trop enthousiastes et répondent à votre commentaire dans les 10 prochaines minutes, rappelez-vous que vous devez répondre à leurs commentaires lentement.

Votre but ici est de rendre leur demande de fusion périmée. Les demandes de fusion ouvertes et périmées sont considérées comme une dette technique parce qu'il faut du temps pour les maintenir.

Si votre collègue a créé une demande de fusion le lundi et que vous avez fait un commentaire le même jour (pour éviter qu'une demande de fusion ne soit fusionnée), répondez à ses modifications dans les 24 heures. Retardez votre réponse d'au moins 24 à 48 heures.

La situation idéale est celle où la demande de fusion de quelqu'un d'autre est fusionnée avant la sienne, ce qui entraîne un conflit de fusion.

C'est une excellente occasion de refuser de faire une revue de code jusqu'à ce que le conflit de fusion soit résolu.

Pourquoi perdriez-vous du temps à examiner un code qui pourrait être modifié une fois le conflit de fusion résolu ?

Avant que leur demande de fusion ne soit fusionnée, ils devraient recevoir au moins 2 ou 3 conflits de fusion dans les itérations de revue de code.

S'ils peuvent fusionner leur code sans conflit de fusion, vous répondez trop rapidement.


3. Bien cacher les changements réels dans le code

Gardez à l'esprit que la revue du code est un jeu à deux joueurs. Ils examineront également votre code.

Vous devez dérouter votre adversaire et mettre à l'épreuve ses nerfs ainsi que sa capacité à observer le code dans ces situations.

N'envisagez même pas d'ajouter une description à votre demande de fusion. Ils doivent faire un effort pour apprendre à connaître votre code.

Les refactorisations supplémentaires, les changements de style de code et les changements de code réels doivent être inclus dans chaque demande de fusion que vous créez.

Ainsi, si votre demande de fusion contient 20 lignes de code avec des changements réels, vous devriez inclure 50% de code en plus pour confondre votre adversaire.

Le meilleur résultat ici est de créer une couverture parfaite pour le changement de code réel dans la demande de fusion afin qu'ils l'approuvent aveuglément.


4. Faire des demandes de fusion massives

Lorsqu'une demande de fusion contient 10 à 20 lignes de code, il est simple de la passer en revue.

Cependant, ce n'est pas ce que vous recherchez.

Chaque demande de fusion devrait contenir au moins 1 000 lignes de code réparties sur 10 à 15 fichiers, selon la règle empirique.

Cela étourdira votre adversaire, l'amenant à perdre du temps sur la revue et à perdre progressivement la motivation de faire une revue correcte du code.

Veillez à envoyer fréquemment des messages à vos réviseurs sur Slack afin de faire pression sur eux pour qu'ils approuvent votre demande de fusion le plus rapidement possible.

Rappelez-leur que vos demandes de fusion sont plus importantes que les leurs et que vous ne voulez pas encourir de dette technique en attendant l'approbation.


5. Ignorer leurs suggestions et leurs commentaires

Vos adversaires finiront par laisser des commentaires sur votre demande de fusion. Car, comme le dit l'adage, "tu as gâché mon code hier, je gâcherai le tien aujourd'hui".

Ignorer cette situation est la meilleure façon d'y faire face (effet autruche).

Est-ce qu'ils donnent leur avis sur votre code ?

Demandez à votre ami d'approuver votre demande de fusion afin que vous puissiez la fusionner sans interférer avec leurs commentaires.

Vous ne devriez pas être empêché de fusionner votre demande de fusion parce qu'un abruti a décidé de vous fournir des commentaires valables sur votre code.

Conclusion

Les choses à éviter si vous voulez que vos collègues apprécient leur travail :

• Utiliser un linter pour vous aider à automatiser votre style de code.
• Ne demandez des modifications que lorsqu'elles apportent un avantage par rapport au code existant.
• Examiner rapidement les demandes de fusion
• Répondez aux commentaires de la revue de code dès que possible.
• Prévoyez du temps chaque jour pour la revue du code.
• Lorsque vous demandez des modifications de code, assurez-vous qu'elles sont testées.
• Des demandes de fusion distinctes doivent être créées pour les nettoyages de code.
• Faire de petites demandes de fusion fréquentes.
• Répondre à tous les commentaires, soit en étant d'accord, soit en expliquant pourquoi vous n'êtes pas d'accord.

Source : "Code reviews: a 5-step guide on how to make your colleagues hate you" (Mensur Durakovic)

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

7 signes révélateurs d'un code illisible : Comment identifier et résoudre le problème, par Mensur Durakovic

Situations désagréables : 50 façons professionnelles de dire à quelqu'un d'aller au diable, par Mensur Durakovic

10 vérités difficiles à avaler que l'on ne vous dira pas sur le métier d'ingénieur logiciel, par Mensur Durakovic, ingénieur logiciel

[driskiou]

Pour éviter ces problèmes, il ne faut pas travailler dans des entreprises qui font de la revue de code.