Vous avez peut-être lu la première partie de l' article sur le code de révision par le réviseur (à propos, nous avons déjà réussi à en discuter dans le dernier numéro du podcast Zinc Prod ).
Puisque l'article a gagné beaucoup de likes, j'écris la suite promise sur la révision du code d'autre part - de l'auteur des changements de code
Comme d'habitude, nous dirons MR (Merge Request) au lieu de CL, car peu de gens comprennent le terme CL.
Les instructions originales pour les auteurs de MR selon Google peuvent être trouvées ici , et je donnerai un bref aperçu.
Alors allons-y
Description de MR
Chez Google, la description des modifications est stockée dans l'historique du système de contrôle de version, et avec une forte probabilité, elle sera lue par beaucoup de gens à l'avenir. Par conséquent, la description de MR est très importante.
La première ligne (dans le titre) doit contenir une phrase décrivant ce qui a été fait dans MR. De plus, selon la tradition, un style impératif (impératif) est utilisé, c'est-à-dire Supprimer blablabla , pas supprimer blablabla
La description elle-même doit être informative, contenir une brève description du problème résolu, des liens vers les documents nécessaires (si nécessaire), les tâches du traqueur de tâches et d'autres contextes. Même dans le petit MR, quelque chose comme ça devrait être.
Une description du type "Fix bug" est bien entendu considérée comme inadéquate.
La RM doit être aussi petite que possible
- Le petit MR peut être vérifié rapidement
- La vérification sera plus significative
- Moins susceptible de manquer un bug.
- Pas si offensant si le MR entier est rejeté. C'est très mauvais quand beaucoup de travail est fait, et il s'avère que tout cela n'était pas du tout nécessaire
- Plus facile de pousser les changements, moins de conflits
- Il est plus facile d'obtenir un code de bonne qualité.
- Plus il y a de changements à la fois, plus il est difficile de restaurer le code si nécessaire
Très rarement, il y a une situation où il est impossible de réduire la taille du MR, le brisant en morceaux. Le réviseur a le droit de rejeter la RM si elle est trop grande
Bien sûr, il ne peut y avoir de règle stricte et rapide, laquelle MR sera considérée comme grande, quelle petite. Est-ce que 100 lignes de code sont grandes ou non? Qui sait.
- MR doit faire une chose. Habituellement, ce n'est pas toute la fonctionnalité, mais une partie
- Refactoring séparé dans un MR séparé
La RM doit être petite mais autosuffisante
- Tout ce dont un examinateur a besoin pour comprendre la MR devrait être dans cette MR
- Après avoir injecté le code, le système devrait fonctionner normalement.
- Si une méthode API est ajoutée, les méthodes d'utilisation doivent être démontrées dans le même MR. En d'autres termes, la RM ne doit pas être si petite qu'il serait difficile de comprendre comment elle sera utilisée, quelles conséquences elle entraînera.
- Code de couverture avec tests, et les tests doivent être dans le même MR
Ne prenez pas à cœur
Parfois, les réviseurs ne sont pas très polis, ils peuvent écrire quelque chose de mauvais sur votre code. Ce n'est pas très professionnel de leur part, mais souvent il y a encore un grain de vérité dans de tels commentaires, et cela doit être pris en compte. Ne répondez pas trop durement. Cela ne fera qu'aggraver la situation.
Si vous n'aimez pas le ton de la conversation dans les commentaires, il vaut mieux trouver cette personne et lui parler personnellement, pour lui expliquer ce qui ne vous convient pas.
Si cela n'aide pas, Google conseille de contacter le responsable.
D'après mon expérience, je veux ajouter que souvent une personne qui écrit un commentaire impoli ne donne souvent pas un compte rendu qui peut sembler agressif. Le texte cache la moitié des émotions; par exemple, ce qui est dit sur un ton plaisant et plaisant sous forme de texte peut sembler être un coup dur. Par conséquent, je suis entièrement d'accord avec Google - en cas de malentendu, communiquez uniquement en personne!
Expliquez le code
Si vous êtes invité à expliquer un point du code, demandez-vous si vous pouvez corriger le code afin qu'il soit compréhensible sans explication. Parce que si l'on ne comprend pas, les autres peuvent ne pas comprendre.
Réponse aux commentaires de l'examinateur
Souvent, lorsque le travail est terminé et envoyé au code de révision, il est psychologiquement difficile d'accepter le fait que quelque chose devra également être réparé. Par conséquent, essayez de ne pas percevoir les commentaires du critique avec hostilité, pensez, peut-être qu'il a raison, et le code deviendra meilleur en conséquence.
Cependant, si le réviseur a toujours tort, n'hésitez pas à écrire à ce sujet, en fournissant la réponse avec des arguments et des faits.
Conclusions
En général, comme je l'ai compris dans un document de Google, l'auteur de MR doit tout faire pour faciliter la relecture; pour que le réviseur comprenne pourquoi le code a été créé, comment le code a été créé, il doit y avoir tout le contexte nécessaire à la compréhension, etc.
Il est inévitable que les désaccords soient résolus en parvenant à un consensus sous une forme professionnelle polie.
Dans le prochain numéro de Zinc Selling, nous discuterons certainement de cet article (et bien plus encore), alors assurez-vous de vous abonner à notre podcast , sinon sautez la partie amusante!