🍷 🧑🏽 🤦🏻 Revue de code Terminator. Avis pour lequel vous serez remercié 🚃 👐🏽 👨‍👩‍👧

^{Ginger m'aide à revoir le code. Et quand il n'aime pas quelque chose - aussi un vrai Terminator,}

"Code review Terminator", un collègue m'a appelé une fois après un examen particulièrement productif. D'une part, il divertissait la République tchèque et était agréable. D'un autre côté, un collègue a vraiment appris quelque chose de nouveau, ce qui lui a permis d'écrire un meilleur code. Alors gagnant-gagnant.

Après le changement de travail, les collègues ont également changé. Mais dans un nouvel endroit aussi, ils ont commencé à remercier pour l'examen. J'ai décidé de comprendre pourquoi et de le mettre sur les étagères. Il s'est avéré 11 recommandations.

1. Traiter l'examen comme l'une des principales activités

Laisser quelques commentaires comme «Mais ici, ce n'est pas assez de vérification nulle» ne suffit pas. Il est nécessaire:

Découvrez ce qui devait être fait
Comprendre comment cela a été fait
. ( , , )?
, , . — , .

2.

C'est une chose de s'asseoir à côté d'un collègue et de discuter de quelque chose, en regardant un écran. Une autre chose est de revoir le code sur le github ou le bitbucket. Il est facile de mal comprendre les intentions d'un collègue lorsque la communication se produit dans le texte. Prenez la phrase «Il y a un bug dans cette ligne». Oui, il est clair que la phrase indique que l'article contient un bogue. Mais on pouvait lui dire avec différentes émotions: colère, surprise, joie que le bug ait été attrapé et ne soit pas entré en production. Ou peut-être avec indifférence.

Votre collègue peut mal comprendre vos intentions - et cela conduit au ressentiment, à la tension dans l'équipe et en général, c'est nul.

Simplifiez-vous la vie: adoucissez la phrase, transformez-la en question ou ajoutez peut-être un visage souriant.

3. Allouer du temps

Pour vous assurer que le code fonctionne correctement et correctement, vous devez bien le comprendre. Et cela prend du temps; assurez-vous de le mettre en évidence suffisamment. N'oubliez pas que l'examen des parties de l'application que vous ne connaissez pas prendra encore plus de temps.

En général, c'est le revers d'une bonne critique: cela prend du temps. Si vous n'avez pas le temps de bien le faire, essayez de reporter ou de nommer quelqu'un d'autre (cela ressemble à l'avis d'un procrastinateur, mais les situations sont différentes). Si ce n'est pas une option, mais que vous devez faire un examen - n'oubliez pas que vous sacrifiez la qualité. Bien que nécessaire, mais un compromis. Si vous en faites une habitude, vous obtiendrez plus de dettes techniques à l'avenir.

4. Ne faites pas d'hypothèses; demander

Lorsque vous rencontrez un code étrange ou une solution trop complexe à une tâche apparemment simple, ne présumez pas par défaut qu'un collègue a fait une erreur ou un mauvais choix. Peut-être est-il au courant de certaines circonstances que vous ne connaissez pas. Vous pouvez simplement clarifier et éviter le risque de situations inconfortables et stressantes si vous blâmez injustement quelqu'un. Par exemple: «Peut-être pouvez-vous utiliser une telle classe ici? Pour autant que je sache, il serait un bon candidat ici et ce serait plus facile que la mise en œuvre proposée. »

5. Détectez les situations où vous devez contacter directement

En règle générale, les révisions sont effectuées de manière asynchrone. Ainsi, vous pouvez vous immerger dans le code et distraire moins votre collègue. Mais dans certaines situations, il est préférable de contacter directement (en montant ou en appelant):

Quand les délais sont épuisés. Une rétroaction rapide accélère les décisions. Mais proprement: avec des délais et ainsi de suite, tout est armé, et les distractions vont ennuyer et faire baisser la concentration.
Erreurs grossières. Les discuter publiquement peut être très embarrassant et frustrant pour quelqu'un. Il vaut mieux parler en personne et expliquer le problème. C'est peut-être juste un oubli, ou peut-être un manque de connaissances - qui est maintenant comblé.
Approche complètement fausse choisie. Pour dire à une personne que vous devez jeter son travail, vous devez être prudent. Il est préférable d'utiliser le langage corporel et l'intonation pour transmettre des clarifications sans offense.

Eh bien, c'est une bonne idée d'ajouter un résumé de conversation au système de révision.

6. Lisez d'abord le ticket

Certaines exigences peuvent ne pas être couvertes par une demande d'extraction apparemment correcte. Pour éviter cela, lisez d'abord l'énoncé du problème. En même temps, cela aidera à comprendre ce qui se passe généralement dans les changements.

7. Justifiez vos suggestions

Certaines erreurs (fautes de frappe, par exemple) n'ont pas besoin d'explication. Mais si vous proposez une solution architecturale alternative ou un autre nom, expliquez les avantages et les inconvénients des deux options. Ce qui vous semble évident peut ne pas être complètement évident pour les autres.

De plus, il y a un proverbe: «Donnez un poisson à un homme et vous le nourrissez un jour. Apprenez-lui à pêcher et vous le nourrissez à vie. » Lorsque vous avez enseigné une nouvelle approche à un collègue, il pourra l'utiliser à l'avenir et mieux écrire le code. Dans le même temps, la qualité du projet s'améliorera également en prime.

8. Louez les bonnes décisions

Un examen ne doit pas nécessairement être une liste d'erreurs. Si vous avez vu un bon endroit, une solution intéressante, une méthode utile - parlez-moi-en. Un bref commentaire "Cool décision" peut améliorer l'humeur d'une personne pour toute la journée. Oui, et ne louez pas les mauvaises demandes de pull: c'est tendu et détruit le sens de l'idée.

9. Soyez poli

Astuce: une phrase comme " Pouvons-nous s'il vous plaît nous débarrasser du style de syntaxe de commentaire de réseau stupide endommagé par le cerveau? " un certain type de commentaires, par courtoisie, en ajoutant «s'il vous plaît»).

10. Aide

Si, au cours du processus de révision, vous avez analysé plusieurs fichiers et par conséquent trouvé une solution alternative - jetez les liens du collègue vers ces fichiers. Vous pouvez même avec des numéros de ligne, c'est encore plus pratique. Cela ne prendra pas beaucoup de vos efforts, mais un collègue peut gagner beaucoup de temps.

11. Suggérer, ne pas indiquer

Lorsque vous proposez une approche différente de l'examen - ne dites pas à votre collègue, par ordre, d'utiliser votre option. Argumentez et laissez votre collègue décider. Très probablement, il suivra vos conseils. Et sinon, quelle pourrait être la raison?

Les deux approches sont à peu près les mêmes. S'il n'y a aucune raison objective de choisir une nouvelle approche, alors il n'y a aucune raison de perdre du temps et de l'appliquer. Avertissement: l'uniformité du code est une raison objective.
Il y a une raison objective pour laquelle votre approche est meilleure. Mais pour une raison quelconque, l'auteur du code ne le comprend pas. Revoyez votre argument, expliquez-le à nouveau - et vérifiez en même temps si vous vous trompez.
Conflits personnels. C'est de la glace glissante et vous devez agir avec précaution ici. Et cela dépasse déjà le cadre du sujet de la revue.

C'est tout. Résumé:

améliorez un peu le monde autour de vous. Faites de bonnes critiques.

UPD. Cet article est une traduction gratuite de mon original en anglais . Converti de "traduction" en "article" afin de ne pas dérouter les lecteurs.

Revue de code Terminator. Avis pour lequel vous serez remercié