Si vous voulez la réponse sans lire, eh bien la voici. Il existe de nombreux objectifs, mais le plus important est que vous et vos examinateurs identifiiez explicitement ceux qui vous intéressent. J'espère que vous continuerez à lire quand même.

La revue de code est une pratique acceptée du développement logiciel moderne. Dans ma carrière, cela a toujours été prêché comme un évangile, mais j'ai de plus en plus découvert que le « pourquoi » a toujours été flou. Il y a beaucoup de bonnes raisons, mais chaque fois que je demande à une nouvelle personne (surtout si elle a des antécédents dans différentes entreprises et équipes), j'obtiens une réponse légèrement différente. Plongeons dedans.

Qu'est-ce que la revue de code ?

La revue de code est la pratique consistant à demander à plusieurs personnes d'examiner un morceau de code. Généralement, une personne écrit le code et une autre le révise plus tard. Parfois, la deuxième personne signe le code avant qu'il ne puisse atterrir dans la base de code. Parfois, la deuxième personne le regarde plus tard. Parfois, le programme de paires de deux personnes ou plus.

Souvent, le critique est plus expérimenté que l'écrivain, mais pas toujours. Parfois, la personne la moins expérimentée passe en revue.

Pourquoi faire une revue de code ?

En fin de compte, toutes ces raisons se résument à une thèse "Deux yeux valent mieux qu'un". Ou "quatre yeux valent mieux que deux" je suppose… à moins que vous ne soyez un cyclope écrivant du code, mais vous avez compris. Mais cela a un coût. Quatre yeux coûtent plus cher que deux (temps/argent/etc). Voyons exactement pourquoi quatre yeux valent mieux que deux. Ceux-ci proviennent de mon enquête informelle auprès de personnes que je connais dans le domaine.

• Aide à diffuser les connaissances dans une équipe
• Aide à éviter les points de défaillance uniques
• Aide à trouver des bogues de bas niveau dans des morceaux de code à risque
• Aide à valider les décisions architecturales de haut niveau dans le code
• Les humains font naturellement un meilleur travail d'écriture de code s'ils savent que quelqu'un d'autre le regardera et le jugera.
• Donne aux nouveaux ingénieurs une chance de voir comment les ingénieurs expérimentés écrivent du code.
• Aidez à éviter que les nouveaux ingénieurs ne causent des problèmes par accident
• Donne aux ingénieurs seniors une chance de superviser/bloquer le code
• Pour passer l'audit. De nombreuses normes de conformité exigent que plusieurs personnes approuvent chaque logiciel déployé.

Je crois que la partie la plus importante de la révision du code est d'être explicite sur l'objectif. S'il y en a un à retenir, c'est celui-ci.

Il n'y a rien de plus frustrant que de recevoir des commentaires au mauvais niveau d'altitude. Obtenir une critique pleine de pinailles lorsque l'idée générale est mauvaise, c'est nul. À l'inverse, obtenir un avis vous indiquant que votre architecture globale est mauvaise, alors que vous le savez déjà et que vous la choisissez délibérément pour une autre raison (par exemple, pour gagner du temps).

Il incombe à la fois à l'examinateur et à l'évalué de s'assurer que l'altitude est explicite et convenue. Si vous n'êtes pas aligné sur cela, presque par définition, vous ne serez pas d'accord sur les résultats et l'examen ne se déroulera pas bien. Il n'y a pas de règle absolue sur qui devrait le faire, mais quelques bonnes règles empiriques

• L'ingénieur le plus expérimenté a plus de responsabilité pour choisir l'altitude
• La personne ayant plus de connaissances sur cette partie de la base de code devrait choisir l'altitude
• La personne la plus responsable des conséquences doit choisir l'altitude (le propriétaire)

En tant que celui qui examine le code, essayez d'être explicite sur le niveau d'altitude que vous souhaitez modifier. Notez qu'il peut être difficile de répondre à cette question tant que vous n'avez pas terminé l'examen. C'est une bonne pratique de rédiger un avis, puis de décider de l'altitude, puis de modifier votre avis rédigé. Par exemple, débarrassez-vous de vos commentaires nits si l'approche est mauvaise.

Si vous trouvez toujours que l'examen est frustrant, retournez votre chaise ou téléphonez et soyez sur la même longueur d'onde à propos de l'altitude !

S'améliorer en ingénierie grâce à l'examen

Dans une relation d'évaluation senior/junior (dans les deux sens), cela peut être un moyen très précieux de s'améliorer en ingénierie ! Ces examens ne concernent pas seulement le code à portée de main, mais également les compétences d'apprentissage. Dans ces scénarios, si vous pouvez vous permettre le détour, cela vaut souvent la peine de prendre un peu plus de temps juste pour apprendre.

J'ai également découvert que lorsque j'étais plus tôt dans ma carrière, il était vraiment utile de consacrer plus d'efforts que nécessaire à mes descriptions de relations publiques et à mon réglage d'altitude - en résumant très bien même les critiques où cela n'était probablement pas nécessaire. J'étais mal calibré sur les parties importantes, et l'effort supplémentaire a vraiment aidé mes collègues plus âgés (qui étaient également occupés) et m'a aidé à m'améliorer moi-même.

Ignorer l'examen

Si aucune des raisons ci-dessus ne semble vraiment convaincante, il peut être acceptable d'ignorer l'examen dans votre organisation. Peut-être que tout le monde est pair, que des points de défaillance uniques sont tolérables ou que les enjeux sont faibles et que la vitesse est primordiale. Il y a des cas où cela est utile, c'est donc définitivement une option sur la table.

J'ai adoré travailler dans des organisations avec une révision de code facultative où celui qui écrit le code est responsable de la prise de décision. Si je décide de sauter l'examen et que cela cause un sérieux problème, j'ai l'impression d'avoir laissé tomber tout le monde, ce qui est honnêtement une excellente motivation pour faire du bon travail. Cela me permet de décider de ma confiance en un RP, ce qui est une compétence importante en ingénierie.

Continuez à lancer le code !