Les révisions de code provoquent souvent des controverses. Lors de la préparation de la conférence «Nous apprenons du comportement toxique dans l'examen du code» à la conférence AlterConf, j'étais prêt à entendre un tas d'objections et de critiques. Mais elle ne s'attendait pas à ce que la communauté soutienne autant l'idée. J'ai assumé la résistance, mais la communauté m'a très bien reçue et m'a approuvée.

On m'a demandé de partager les diapositives , mais maintenant je pensais que les diapositives elles-mêmes étaient de peu d'utilité et étaient sorties de leur contexte: elles manquaient d'explications. J'ai donc décidé de publier cet article. Plus tard, les organisateurs de la conférence ont mis en ligne une vidéo .

Voici quelques types de comportements de révision de code improductifs et des recommandations sur la façon de rendre le processus plus convivial et d'éliminer la toxicité. Tous les modèles comportementaux ont été testés par moi ou dans une entreprise que je connais. Dans le passé, de tels péchés m'ont également été apportés.

Comportement improductif n ° 1: communiquer l'opinion comme un fait

Ne faites pas de déclarations si vous ne pouvez pas vous référer à la documentation, aux recommandations formalisées et aux exemples de code à l'appui de ces déclarations. Les gens devraient savoir pourquoi on leur demande d'apporter des modifications, et les préférences personnelles d'un autre développeur ne sont pas un argument suffisant.

Au lieu de dire:

Ce composant doit être rendu apatride.

... il vaut mieux fournir un peu de contexte:

Étant donné que ce composant n'a pas de méthodes de cycle de vie ou d'état, il peut être rendu sans état. Cela améliorera les performances et la lisibilité du code. * Ici * de la documentation.

Le transfert d'opinion en tant que fait se retrouve souvent dans les discussions sur le style et la syntaxe. Ce sont des sujets vraiment importants, mais pas pour les révisions de code, car le style et la syntaxe n'ont rien à voir avec le problème que le développeur résout initialement.

Il est préférable de mener ces discussions séparément et de déterminer le style pour toute l'équipe. Implémentez le linter et les correctifs de code automatiques . Vous vous référerez ensuite à ces recommandations de style, pas à votre opinion personnelle.

Il est particulièrement important de ne pas donner votre opinion comme un fait si vous avez un rang et une autorité plus élevés dans une équipe ou une entreprise. Le développeur a l'impression qu'il n'a d'autre choix que de répondre docilement à vos exigences.

Comportement improductif n ° 2: avalanche de commentaires

Lorsqu'une personne fait une erreur, il y a de fortes chances que cette erreur se produise à plusieurs endroits. J'ai remarqué que les examinateurs indiquent parfois chacun des cas au lieu de laisser une note détaillée avec des liens vers des ressources utiles.

La consolidation des commentaires vous permet d'envoyer le même message sans supprimer l'auteur. Une avalanche de commentaires en double sur un problème ressemble à une piqûre.

Improductif et accablant:



Commentaires multiples pour une erreur récurrente (espaces à la fin de la ligne)

Une option plus utile:


Commentaires consolidés

Je peux comprendre que, parfois, il est utile de pointer chaque endroit de l'erreur, car le commentaire disparaît lorsqu'il est corrigé dans les validations suivantes. Mais si l'erreur se produit plusieurs fois, il est évident que le développeur n'était pas au courant d'un guide spécifique, et il devrait simplement indiquer les bonnes ressources.

Comportement improductif numéro 3: demandez aux ingénieurs de résoudre les problèmes des autres, "pendant qu'ils sont ici"

Ne demandez pas aux développeurs de traiter des problèmes qui ne sont pas directement liés à l'ensemble des modifications ou au problème que ce code tente de résoudre. Même si un développeur développe ou modifie du code sale avec une abondance de mauvaises pratiques, ne lui demandez pas de nettoyer et de corriger cet étrange code.

Je ne propose pas de priver les développeurs de la responsabilité du code simplement parce qu'ils ne l'ont pas écrit initialement. En fait, ce n'est pas bon de dire quelque chose comme "Le code de quelqu'un d'autre n'est pas mon problème". Il est juste plus approprié de créer un ticket séparé et une requête pull pour corriger le code sale. Ainsi, vous évitez une forte augmentation du volume de travail de quelqu'un, ce qui résout le problème de la dette technique.

TL; DR : Ne demandez pas au développeur de résoudre les problèmes "pendant qu'ils sont ici". Si le code fait ce qui est requis dans le ticket et n'introduit pas de nouveaux problèmes dans la base de code, approuvez-le, puis créez un ticket pour effacer la base de code.

Comportement improductif n ° 4: poser des questions de condamnation

Évitez de condamner des questions comme celle-ci:

Pourquoi n'avez-vous pas simplement fait ____ ici?

Cela implique qu'une solution simple devrait être évidente. Cela oblige le développeur à se défendre.

Souvent, ces questions condamnantes ne sont que des demandes voilées. Au lieu de cela, proposez une recommandation (avec documentation et liens), en omettant les mots durs.

Vous pouvez faire ____, ce qui a l'avantage de ____.

Comportement improductif n ° 5: sarcasme

Il n'y a pas de place pour le sarcasme dans les critiques. En règle générale, les commentaires sarcastiques ne fournissent pas de contexte et de rétroaction efficace. Décrivez plutôt le problème en détail et faites des recommandations, mais laissez de côté les blagues caustiques.

Improductif:

Avez-vous même testé ce code avant de le soumettre?

Utile

Omission de saisir un nombre négatif. Pourriez-vous s'il vous plaît faire cela?

Voici un autre exemple de commentaire dans une revue de code qui n'est ni drôle ni utile:

Nous ne sommes pas mauvais, nous sommes impitoyables. Comme vous pouvez le voir, j'ai écrit "bip!" - Lors de l'importation de chaque fichier que vous touchez. Je pensais à ce qui suit: «Votre importation viole notre convention standard, ce qui suppose un certain ordre: d'abord, les modules intégrés, puis les tiers, puis le niveau du projet», mais cette phrase est trop longue pour être tapée dans chaque cas.

Dans l'exemple ci-dessus, "bip!" - complètement inutile et sans signification. C'est un humour pédant qui n'aide pas l'auteur.

Comportement improductif # 6: Emoji au lieu de décrire le problème

Lorsque vous signalez des problèmes dans le code, évitez les émoticônes avec le pouce vers le bas ou les emoji avec un petit homme écœurant. Il est aussi inutile que le sarcasme, pour les mêmes raisons. Les emoji sont mystérieux, faciles à mal interpréter. Les gens perdent du temps à essayer de comprendre vos pensées.


N'utilisez pas d'emojis pour indiquer des problèmes de codage

Dans tous les cas, vous ne devriez pas avoir de réaction émotionnelle aux erreurs de programmation.

Il est tout à fait normal d'utiliser des émoticônes positives, telles que «pouce levé» ou «cheers!», Mais pas pour indiquer des problèmes, mais en réponse à un bon code.


Approuver les émoticônes est super

Comportement improductif n ° 7: ne répondez pas à tous les commentaires

Les auteurs contribuent également à la toxicité de la discussion. Si vous combinez le code sans répondre à tous les commentaires, cela est surprenant pour la personne: il a essayé de vous aider, et vous précisez que certaines critiques n'ont pas d'importance.

Si le commentaire n'est pas pertinent ou si vous n'agissez pas, expliquez brièvement pourquoi.

N'ignorez pas vos collègues.


Combiner du code sans répondre à un commentaire

Comportement improductif n ° 8: ignorer le comportement toxique s'il provient de professionnels de haut niveau

Le comportement toxique ne doit pas être ignoré ou sous-estimé simplement parce que le développeur est un excellent professionnel et un employé extrêmement productif. Bien qu'il fasse un travail fantastique, il est important de garder à l'esprit que son comportement toxique entraîne le stress et l'épuisement des autres développeurs.

Expérience avec une personne qui présente un comportement toxique:

D'autres trouveront que travailler avec cette personne épuise et démotive. Ils feront tout pour éviter d'interagir avec lui, même si cela affecte négativement leur capacité à effectuer des tâches. Les communications dans toute l'organisation seront interrompues et les employés commenceront à chercher du travail ailleurs. Alors que vous faites face aux conséquences d'une fuite des talents et des projets infructueux, ce développeur particulier continuera de travailler calmement comme si de rien n'était. - Joseph Gefro

Si des mesures ne sont pas prises pour rectifier la situation, des conséquences graves sont possibles: les développeurs seront surchargés, attaqués et démotivés. Ils commenceront à craindre les commentaires, ce qui devrait en fait les aider à grandir.

Personnellement, je me sentais très inquiet chaque fois que je recevais un e-mail contenant des commentaires sur ma demande de retrait d'un ancien collègue (connu pour ses critiques toxiques et inutiles). Bien que le comportement toxique affecte chacun différemment, mais certainement personne ne profite de cette toxicité.

Remarque : Je tiens à préciser que si le développeur n'a pas pu résister et a une fois montré un tel comportement, cela ne le rend pas «toxique». Nous parlons d'insultes répétées et de commentaires caustiques.

Pratiques utiles de révision du code

Voici quelques recommandations qui s'appliquent à toute communication normale, bien que nous parlions ici dans le contexte de la programmation et des révisions de code.

Comportement utile n ° 1: utilisez des questions ou des recommandations pour créer un dialogue

Ne demandez jamais aux gens d'apporter des corrections ou de poser des questions désapprobatrices, car cela interfère avec le dialogue entre vous et l'autre personne.

Pourquoi n'avez-vous pas simplement combiné ces conversions dans un fichier avec des constantes?

Formellement, c'est une question, mais cela ne crée pas de dialogue entre vous et l'interlocuteur. Il le fait juste se défendre. Demandez plutôt ce que l'autre personne pense de votre décision, par exemple:

Que pensez-vous de tirer ces conversions dans un fichier constant? Il y en a beaucoup, donc un fichier séparé pourrait bien avoir du sens pour le moment.

... ou faites une recommandation:

Dans ce fichier, vous avez de nombreux appels de traduction pour la «fonction x». Il peut être judicieux de créer un fichier séparé avec ses constantes.

Comportement utile n ° 2: Collaborez, ne vous cachez pas

Lorsque vous programmez ensemble, vous devez être présent, poser des questions, discuter et indiquer des ressources.

«… Lorsque vous voulez aider ou travailler ensemble, vous devez être pleinement impliqué, pas simplement intervenir parfois» - Guide du centre des infirmières et infirmiers

Comportement utile n ° 3: répondre à chaque commentaire

Si vous, en tant qu'auteur, ne prévoyez pas d'appliquer les conseils d'un critique, notez-le simplement en le signalant. N'ignorez pas ceux qui prennent le temps de vous aider.

Par exemple:

Personne A: - Que pensez-vous de la création d'une fonction d'assistance pour cet appel d'API? Sinon, tout va bien.

Personne B: - Cette ligne ne faisait pas partie de mon ensemble de modifications. Je vais combiner le code, créer un ticket séparé sur GitHub et l'écrire dans le plan de travail pour notre groupe.

Comportement utile n ° 4: savoir quand organiser une réunion en personne

Après des dizaines de commentaires et de solutions proposées, il devrait être clair que la communication en ligne est devenue improductive pour le problème en question. Envoyez une invitation à tous vos collègues impliqués.

Ainsi, le groupe pourra rapidement prendre une décision et l'appliquer.

Les problèmes qui prennent des heures et des tonnes de commentaires peuvent généralement être résolus en quelques minutes de conversation productive. - "Neat Java"

Comportement utile n ° 5: utilisez les opportunités d'apprentissage et ne vous montrez pas

Avant de participer à une révision de code, demandez-vous:

Votre commentaire vous aide-t-il vraiment à apprendre ou trouvez-vous des défauts?

Pensez à votre commentaire. N'oubliez pas que l'objectif d'une révision de code est d'enseigner et d'aider les autres développeurs à se développer. Ce n'est pas une plateforme de performances.

Comportement utile n ° 6: ne montrez pas de surprise

Faites attention de ne pas vous surprendre si une personne ne sait pas quelque chose. Ne dérangez pas les gens qui devraient déjà connaître ces informations. À l'inverse, n'hésitez pas à admettre que vous manquez d'expérience sur le sujet - c'est un excellent moyen de demander de l'aide.

Voir la règle «Ne faites pas semblant d'être surpris» dans le didacticiel du Centre des infirmières et infirmiers pour plus d'informations.

Comportement utile n ° 7: automatisez tout ce que vous pouvez

Il est peu logique de discuter des bogues qui peuvent être détectés par les linters, les crochets Git ou les tests automatisés. Ceci est une tonne de commentaires supplémentaires qui ressemblent à des piqûres. Les gens ne savent pas très bien identifier de telles erreurs et des outils d'automatisation ont donc été créés.

Il existe également des outils pour exécuter automatiquement des tests lors de l'ajout de nouveau code. Ils affichent des avertissements si un ensemble de modifications viole l'un des tests. Par exemple, TeamCity et Jenkins CI.

Utilisez également des hooks Git pour exécuter des tests et des linters sur le nouveau code. Ils intercepteront le commit s'ils trouvent des bugs.

Laissez l'outil indiquer les problèmes, afin que les gens n'aient pas à le faire.

Comportement utile n ° 8: ne pas dépasser le comportement toxique

Il n'est pas nécessaire d'adopter un comportement toxique dans votre révision de code, car cela ressemble à de la vengeance ou à un rituel de bizutage pour les nouveaux développeurs.

Trouvez des collègues qui vous soutiendront.

Si vous remarquez des révisions de code improductives, essayez d'en parler à un collègue, parlez directement et honnêtement (si vous vous sentez en sécurité dans votre poste / entreprise).

Comportement utile n ° 9: Les gestionnaires, étudient attentivement les candidats, écoutent l'équipe et utilisent votre autorité

Les managers ont de grandes opportunités pour créer une atmosphère positive et favorable dans l'équipe.

Nous reformulons les conseils de l'article «Nocif pour les développeurs toxiques» :

• Empêchez les développeurs toxiques d'apparaître dans l'équipe. Lors de l'embauche, faites attention non seulement à la formation technique. Découvrez comment le candidat collabore et communique. Analysez son travail de manière critique et voyez comment il réagit. Assurez-vous que chaque candidat améliore la culture de l'entreprise, et pas seulement qu'il s'y intègre.
  
• Lorsqu'un développeur toxique est toujours entré dans l'état ou hérité, demandez à chaque employé un avis à ce sujet dans une conversation personnelle. Si le développeur est toxique, il apparaîtra dans les critiques à son sujet.
  
• Parlez à un développeur toxique. Donnez des exemples spécifiques de commentaires efficaces dans une révision de code. Travaillez continuellement avec lui, en continuant à collecter des informations dans des conversations personnelles avec ses collègues et son manager.
  
• N'isolez pas le révélateur toxique. (*)
  
• Répétez aux employés la nécessité d'un environnement convivial.

(*) Bien que l'article propose d'isoler les développeurs toxiques, je considère qu'il est important d'encourager le développeur toxique à travailler avec l'équipe, mais de manière plus saine. L'isolation ne résoudra pas le problème. Si vous lui donnez un travail séparé, la toxicité diminuera à court terme, mais le développeur n'abandonnera pas son comportement improductif. Il ne perdra que le podium pour le démontrer.

Comportement utile n ° 10: définir la norme alors que l'équipe est petite et en pleine croissance

Les petites équipes peuvent accepter de nouvelles idées et les mettre en œuvre. Même si vous ne jugez pas nécessaire de fixer des normes, car maintenant il n'y a pas de problèmes, mais il est important de maintenir de bonnes pratiques de coopération lors de la reconstitution.

Comportement utile n ° 11: comprendre que vous pouvez faire partie du problème

Pour créer un environnement plus favorable, il est important d'être honnête avec vous-même et de réfléchir à tout comportement inefficace.

En tant que junior, j'ai remarqué plusieurs fois une erreur dans le code de quelqu'un et j'étais content, car je pouvais laisser un commentaire! Je comprends maintenant que j'ai profité de cette occasion pour me vanter et non pour aider. Vous devez évaluer soigneusement vos actions.

Je pense qu'il est utile pour tout le monde de prendre le temps de cette introspection difficile.

Et le dernier ...

Nous ne parlons pas du contenu des critiques, mais seulement du ton

Je sais que les examens sont importants et nous ne nous battons pas contre eux. Je ne vous demande pas de compromettre la qualité du code. La culture bienveillante de la révision du code et la haute qualité du code ne devraient pas s'exclure mutuellement.

J'espère simplement que les gens prendront des mesures pour fournir des commentaires constructifs et efficaces et créer des conditions plus favorables dans lesquelles les développeurs se sentiront à l'aise, apprendront, grandiront et n'auront pas peur de faire des erreurs. Nous pouvons tous nous améliorer ensemble.