👨‍✈️ 😪 🦃 Examen du code - améliorer le processus 🐠 🧠 🎶

Imaginez une équipe où la révision du code n'est pas effectuée. Les développeurs écrivent du code et, sans vérification, apportent toutes les modifications à la branche principale. Après un certain temps, la fonctionnalité se développe ou des bogues sont trouvés, ils reviennent au code source, et là toutes les variables sont nommées avec une seule lettre, il n'y a pas d'architecture et la qualité n'est pas la meilleure. Ce code de mauvaise qualité s'accumulera et un jour viendra le moment où, avec peu d'innovation, le projet commencera à s'effondrer: dans le meilleur des cas, le temps de développement augmentera, dans le pire des cas, l'accompagnement du projet deviendra impossible. Et cela malgré le fait qu'il était une fois la tâche terminée et que tout fonctionnait bien.

Comment éviter cela?La réponse à la question du titre est Revue de code.

La révision de code est une vérification de code pour les erreurs qui améliore la stabilité et la qualité du code.

Imaginez maintenant une équipe où la révision du code est déjà en cours, mais dans le processus, les développeurs jurent entre eux, la requête Pull n'est pas approuvée depuis longtemps, les tâches commencent à geler. Le processus depuis le début de la tâche jusqu'à son apparition dans le projet est étiré, et avec lui tout le travail est ralenti.

La demande d'extraction / demande de fusion est une demande à l'équipe de projet (personne ou groupe de personnes) d'approbation et d'application des modifications à la branche sélectionnée. Dès que la demande Pull est créée, une discussion du code écrit a lieu avant l'approbation. Des changements peuvent être suggérés au cours de la discussion. Après approbation, les modifications actuelles tombent dans la branche sélectionnée.

Vous trouverez ci-dessous des recommandations pour accélérer la révision du Code et améliorer sa qualité.

Nous divisons la question en trois parties et les considérons séparément:

Partie technique: comment vérifier le code et que rechercher lors de la vérification?
Partie communication: comment prévenir les différends et réduire le stress pendant la discussion?
Partie organisationnelle: que peut-on faire pour rendre le processus de révision du Code efficace?

Partie 1. Vérification du code

Exécutez le code d'auteur à la maison

Exécutez le code par vous-même et voyez comment les modifications fonctionnent en conjonction avec le reste du code. Cela aide à trouver les zones à problèmes qui ne sont pas visibles dans l'interface Web. Essayez de voir le code de manière exhaustive, évitez de vous concentrer uniquement sur les changements locaux. Ainsi, vous comprendrez rapidement le code et trouverez rapidement les inexactitudes architecturales, le cas échéant.

N'oubliez pas l'expérience utilisateur

Faites attention à la façon dont les modifications du code affecteront l'utilisateur final. Même le code le plus magnifiquement écrit peut être inutile pour les utilisateurs, ce qui entraînera des tâches supplémentaires, des bogues et peut également porter atteinte à la réputation de l'entreprise et du produit.

Nous regardons la logique générale

Les développeurs peuvent résoudre avec succès leur problème, mais interrompre le travail d'autres morceaux de code. Pour éviter que cela ne se produise, regardez non seulement comment une tâche spécifique est résolue, mais aussi comment les changements affecteront le travail d'autres services, modules et l'ensemble du projet dans son ensemble.

Nous regardons l'architecture de code

L'architecture du code détermine combien de temps nous consacrerons à l'avenir à l'extension, à l'ajout de fonctionnalités ou à la modification d'un bogue. De plus, l'architecture du code peut affecter l'apparence potentielle des bogues en cas de changements dans le projet. Idéalement, l'extension et l'ajout de nouvelles fonctionnalités ne devraient pas conduire à une refactorisation.

Nous écrivons plus facilement

Faites attention à la re-complication du code: plus le code est simple, plus il est facile à lire et à entretenir. Débarrassez-vous des morceaux de code complexes.

Multithreading

Si le projet implique de travailler dans plusieurs threads, voyez ce qui se passe s'il y a un retard pendant l'exécution du code dans l'un des threads, et comment ces cas sont traités.

Optimisation excessive

Comme l'a écrit Donald Knuth classique, l'optimisation prématurée est la racine de tout mal. Il est préférable d’optimiser uniquement ce qui est nécessaire ici et maintenant.

Nous résolvons les erreurs

Faites attention au comportement du projet s'il n'a pas été possible d'exécuter une ligne de code, un bloc de code ou une requête au serveur. Souvent, les développeurs interrompent l'exécution d'une fonction sans sortie d'erreur, mais de tels cas doivent être résolus.

Conformité

Le code doit respecter l'accord, le style de code. L'uniformité du code n'est pas un caprice, mais une nécessité: un tel code est plus facile à maintenir et il est plus facile de comprendre ce code.

Noms et apparence

N'oubliez pas les autres programmeurs qui devront comprendre votre code. Le code lisible simplifie sa prise en charge supplémentaire. Les noms doivent être compréhensibles et décrire avec précision la classe, l'objet, la fonction, etc.

Commentaires sur le code

Les commentaires devraient répondre à la question: «pourquoi est-ce fait?», Et non «comment est-ce fait?». N'oubliez pas cela.

Partie 2. Nous discutons

La principale règle de discussion: tout commentaire doit viser le code, et non la personne qui l'a écrit. Cela fonctionne dans la direction opposée - ne prenez pas les commentaires comme une critique de vous personnellement. La tâche de la révision du code est d'améliorer votre code, car ce que vous n'avez pas remarqué peut être remarqué par d'autres. Les collègues peuvent proposer des solutions alternatives, et c'est le potentiel de croissance professionnelle. Il est important de se rappeler que la discussion du code n'est pas un concours d'esprit ou une démonstration de «qui en sait plus», donc le sarcasme, l'agression cachée et la grossièreté y sont inappropriés.

En règle générale, la demande d'extraction est effectuée sur des services d'hébergement Web spéciaux (github.com, bitbucket.org, gitlab.com, etc.), où il est possible de visualiser les modifications et de laisser un commentaire sur un morceau de code spécifique.

Nous respectons l'accord

Encore une fois, le code doit respecter l'accord. Cependant, si un tel accord n'existe pas, vous ne devez pas demander à un collègue d'ajouter un espace ou un retrait dans le code.
Dans les moments controversés, vous pouvez être d'accord avec toute l'équipe dans le processus de révision du code, mais demander à suivre ces règles est préférable lors de la révision de code suivante, il sera donc plus facile pour tout le monde de les accepter. Soit dit en passant, une directive documentée dans le style d'écriture supprime presque tous les différends.

Nous offrons une alternative

Évitez les déclarations comme "vous avez mal fait ...", "pourquoi, pourquoi écrivez-vous comme ça?" Ils sont perçus comme des critiques et conduisent à des excuses. Il vaut mieux écrire un commentaire sur le contenu du code, sans recourir à l'identité de l'auteur. Essayez également d'éviter les ordres et la coercition: les gens n'aiment pas quand quelqu'un les commande et perçoivent ces commentaires négativement.

Vous pouvez procéder comme suit:

Nous écrivons ce qui ne va pas avec le code
Pourquoi est-il préférable de ne pas écrire
Nous proposons des options alternatives

Nous restons dans le cadre du problème

Souvent, vous pouvez voir des commentaires sur le code qui était avant et n'a pas touché. Pas besoin de commenter ce qui n'est pas pertinent pour la tâche. Toute modification par un tiers peut prendre beaucoup de temps et peut être perçue négativement. Il est donc préférable de voir comment une personne a terminé la tâche en cours et de ne pas lui demander de refactoriser le projet.

Louange

Si vous voyez une solution intéressante ou cool, n'hésitez pas à faire l'éloge. De plus, c'est une grande motivation pour vos collègues de continuer à écrire du bon code à l'avenir.

Tous les commentaires sont égaux.

Il arrive souvent qu'un programmeur en sache techniquement plus que l'autre, comme en témoigne la gradation du chef d'équipe junior, intermédiaire, senior. Il ne vaut pas la peine de souligner les commentaires d'un groupe comme étant plus importants. Cela dévalue l'opinion de certains développeurs, ce qui peut conduire à l'indifférence et à la participation formelle à la révision du code. Lorsque les opinions de chacun sont tout aussi importantes, la révision du code est plus productive.

Exprimez clairement vos pensées

Pour une communication productive, écrivez le plus en détail possible et expliquez chaque détail. Tout le monde a un niveau de connaissance différent et jusqu'à présent, personne n'a appris à lire dans les esprits.

Poser des questions

N'hésitez pas à demander à vos collègues pourquoi leur option proposée est meilleure que votre option actuelle. C'est une excellente occasion d'apprendre quelque chose de nouveau et d'évoluer professionnellement.

Nous résolvons les conflits

Il arrive qu'une personne n'accepte pas tous les arguments et ne puisse pas proposer le sien, refuse de faire quelque chose. Quelques conseils pratiques pour ce cas:

La plupart des situations de conflit peuvent être résolues en parlant en personne, sur un ton amical.
Vous pouvez concéder, car vous ne pouvez pas écrire de code pendant que vous êtes en guerre.
Vous pouvez attirer toute l'équipe et décider ensemble de la meilleure façon d'écrire le code.
Dans la révision actuelle du code, laissez tout tel quel et séparez les tâches controversées des tâches de refactorisation, car les mots «puis corrigez», en règle générale, ne prennent jamais vie.

Partie 3. Amélioration du processus

Nous décrivons ce qu'ils ont fait

Nous décrivons l'essence de la tâche dans l'en-tête de la demande d'extraction (ou faisons un commentaire séparé) et les étapes qui ont été suivies pour la terminer.

Divisez la demande de tirage en plusieurs parties

Un gros morceau sera regardé pendant longtemps, discuté pendant longtemps et corrigé pendant longtemps. Divisez le code en petites parties logiques - de cette façon, le processus ira beaucoup plus vite.

Répondre à tous les commentaires

Il est conseillé de répondre à chaque commentaire afin que l'équipe n'ait pas d'ambiguïtés. Les autres développeurs doivent comprendre que vous avez lu leur commentaire, effectué le travail nécessaire et apporté des corrections. Ouvrir constamment une demande de tirage et regarder ce qui a été corrigé et ce qui ne l'est pas est très gênant et prend beaucoup de temps.

Rechercher tout?

Il existe différentes approches - rechercher le maximum du possible ou d'abord commenter les moments architecturaux importants, et après correction, prêter attention aux petites choses.
Les deux méthodes ont droit à la vie. Je crois que la deuxième option prend plus de temps: imaginez qu'après la correction, vous devez revoir à nouveau le code, commenter et attendre à nouveau les corrections. Il est beaucoup plus rapide de parcourir attentivement le code une fois, de laisser des commentaires, puis de vérifier les corrections.
S'il y a des inexactitudes architecturales et qu'il est clair que les erreurs mineures disparaîtront elles-mêmes après la réparation de l'architecture, vous ne devriez pas perdre de temps à commenter les détails de cette section du code.

Attendre tout le monde?

Vous ne pouvez pas attendre que tout le monde approuve la demande d'extraction et convenez que l'approbation de 80% des réviseurs est suffisante pour terminer la tâche. Cela accélérera l'entrée du code dans la branche principale, ce qui est sans aucun doute plus bénéfique pour les processus métier, mais peut conduire à des désaccords au sein de l'équipe et à l'indifférence à la révision du code.

La deuxième option consiste à attendre l'approbation de tous les développeurs impliqués. La qualité du code augmentera, mais le processus lui-même ralentira considérablement. Le choix en faveur de la vitesse ou de la qualité, chaque équipe doit faire la sienne.

Petites choses

S'il n'y a pas de commentaires sérieux sur le code, vous n'avez pas besoin d'attendre que toutes les petites inexactitudes soient supprimées. Ils peuvent être indiqués dans les commentaires et approuver immédiatement la demande de pull - l'auteur du code se sentira plus calme, sa loyauté envers l'équipe augmentera, il sentira qu'il a confiance. Et, bien sûr, la vitesse de demande de pull va augmenter.

Conclusion

La révision du code est une partie importante du processus de développement, qui affecte le projet dans son ensemble, il est donc dangereux de l'ignorer. Certaines de ces recommandations aideront à accélérer la révision du code, d'autres l'amélioreront. J'espère que mon expérience et mes connaissances seront utiles aux lecteurs de cet article.

Examen du code - améliorer le processus