Les programmeurs débutants doivent-ils être impliqués en tant que réviseurs de code dans les projets des programmeurs chevronnés?


55

Un des membres de mon équipe, un programmeur junior, possède des compétences impressionnantes en programmation pour son niveau d'expérience.

Et lors de la révision du code, je crois qu’il est important de mettre l’accent sur l’apprentissage, sans signaler les erreurs.

Mais les programmeurs débutants doivent-ils participer à la révision du code pour les programmeurs plus expérimentés? Ou les revues de code devraient-elles être suivies uniquement par des programmeurs ayant l'expérience correspondante?


54
Qu'est-ce que tous ces trucs "junior" et "senior"? L'OMI, qu'un programmeur soit ou non qualifié pour réviser le code des autres personnes, doit être déterminé en fonction de ses capacités et de son expérience - et non du titre ....
Anthill

23
Et le titre devrait normalement être déterminé en fonction des capacités et de l'expérience. Si ce junior est assez bon pour revoir le code des seniors, il est temps de changer de titre.
SuperM

18
Mais parfois, ce titre est déterminé par la politique et les jeux des ressources humaines :)
Michal Franc

4
Qu'entendez-vous exactement par "programmeurs débutants"? S'agit-il de personnes moins expérimentées dans l'application ou simplement moins expérimentées dans l'industrie? D'après mon expérience, il est possible qu'un membre du personnel débutant soit la personne la plus expérimentée sur un projet donné, car ils y ont travaillé le plus longtemps ou le plus récemment.
Thomas Owens

4
@ThomasOwens, par "programmeurs débutants", j'entends les personnes moins expérimentées dans l'industrie.
Md Mahbubur Rahman

Réponses:


62

L'objectif principal d'une révision de code est de rechercher des défauts ou des problèmes potentiels. Les participants à l’examen devraient être les personnes les mieux à même d’identifier ces problèmes, quels que soient leur titre et leur ancienneté.

Par exemple, si une application est en cours de développement en Python et que l’ingénieur débutant a plus d’expérience du langage Python que l’ingénieur principal qui a écrit le code, il peut constituer un atout précieux pour la recherche de méthodes de remplacement, mais peut également avoir moins de connaissances du système dans son ensemble.

Au-delà de l'expérience dans les outils et les technologies, considérons également l'expérience dans le domaine des applications. Une personne ayant 20 ans d’expérience, mais seulement 1 ou 2 dans l’industrie financière peut être aidée par le fait que le développeur soit globalement moins expérimenté et que seulement 5 ans d’expérience, tous dans l’industrie financière examinent son travail.

Inviter des membres du personnel moins expérimentés à observer et à participer autant que possible au processus de révision du code peut également être bénéfique pour leur permettre d’apprendre une base de code, de poser des questions et de savoir ce que l’on attend d’eux dans les révisions de code, code qu'ils produisent. Cependant, vous ne voulez probablement pas que trop de personnes soient impliquées (en se concentrant plutôt sur les personnes pouvant totalement soutenir la révision du code et son objectif) dans le processus.

Cela s’applique vraiment à tout type d’examen - exigences, conception, code ...


4
+1 pour "Les participants requis à l'examen doivent être les personnes les mieux à même d'identifier ces problèmes, quels que soient leur titre ou leur ancienneté." Et aussi pour une excellente réponse.
Md Mahbubur Rahman Le

60
"L'objectif principal d'une révision de code est de détecter des défauts ou des problèmes potentiels." Complètement en désaccord. La révision de code a pour objectif principal le partage des connaissances; Le deuxième objectif d’une révision de code est d’établir une norme de codage; tout bogue trouvé lors de la révision est plus une chance qu'un jugement. programmer.97things.oreilly.com/wiki/index.php/Code_Reviews
pdr

8
@pdr Une norme de codage doit être établie bien avant que la première ligne de code ne soit écrite. Si vous utilisez des critiques pour établir la norme, il est trop tard. C'est peut-être le bon moment pour adapter la norme de codage au fur et à mesure que vous développez - vous pouvez utiliser des examens pour signaler les faiblesses ou suggérer des améliorations à la norme, mais je ne peux pas imaginer démarrer un projet de développement sans une norme (même si c'est juste les lignes directrices suggérées par la langue).
Thomas Owens

5
Comment savez-vous même quoi mettre dans les normes de codage avant le début du projet et il devient clair (à travers la révision du code) que différents membres de l'équipe abordent le même problème de différentes manières? Nous ne parlons pas de casse sur les noms de méthodes, où il y a généralement des normes de langue, nous parlons de choses comme NUnit vs MSTest; modèles de référentiel; la capacité de dire "Hey, j'ai déjà écrit un wrapper pour les clients de la WCF. Jetez un coup d'oeil au mien, prenez le meilleur de chacun et faites-en un standard." Ce truc vient seulement de commentaires de code et est la meilleure raison de les faire.
pdr

4
La structure de test unitaire était probablement un mauvais exemple, mais il est fréquent que deux développements différents exigent qu'un fichier soit décompressé. Deux développeurs différents peuvent utiliser des bibliothèques différentes car ils les ont déjà utilisées. Vous ne pouvez pas avoir TOUTES ces discussions au début, sinon vous aurez du mal à participer à plus de réunions que de développement. Le partage des connaissances, via la révision du code, est la chose la plus importante pour éviter que ces problèmes ne se propagent.
pdr

81

Les programmeurs débutants doivent-ils être impliqués en tant que réviseurs de code dans les projets des programmeurs expérimentés?

Oui ils devraient. C'est une bonne expérience d'apprentissage de lire le code des autres. (Et cela vaut aussi bien pour le bon code que pour le mauvais. Bien que l'on puisse espérer que le code d'un développeur senior ne serait pas mauvais ...)

De toute évidence, il n’est pas sage de n’avoir que des juniors pour la révision du code. Et peu judicieux de placer des attentes trop élevées sur les juniors en termes de ce qu’ils peuvent trouver. Cependant, vous pourriez également être surpris par les nouvelles idées que les programmeurs débutants peuvent apporter.


Une autre réponse mentionnait que les juniors étaient / se sentaient intimidés. Ce n'est PAS ce que devrait être l'examen du code ... pour les examinateurs ou les réviseurs. Si cela se produit, votre groupe doit changer la façon dont il procède à la révision du code ... et peut-être que les intimidateurs doivent être mis en file.


Je pense que ce que veut dire mouviciel, c’est que le code des personnes âgées peut être intimidant, pas les personnes âgées elles-mêmes (si tel est le cas, alors oui, l’équipe a des problèmes plus graves que celui qui doit revoir le code).
Yannis

6
@YannisRizos - 1) Je ne le lis pas de cette façon. 2) C'est là que "il est imprudent de s'attendre à trop" entre en jeu. Si le code de l'aîné est "intimidant", il est donc particulièrement utile pour le développement de l' adolescent de le lire / le comprendre.
Stephen C

1
Apprendre ce que pensent les programmeurs expérimentés est un autre élément précieux des examens de code pour les développeurs débutants. Quand j'étais développeur junior, le code était plus logique une fois que le développeur senior l'avait examiné avec moi.
Michael Shopsin

38

J'ajouterais que si un programmeur "junior" ne peut pas comprendre un code pour personnes âgées, c'est en soi une bonne mesure du code. OK, il peut arriver qu'il soit impossible d'écrire du code que tout le monde puisse comprendre, mais heureusement, il s'agit d'exceptions. Si seulement 1 ou 2 personnes peuvent comprendre le code, que se passe-t-il lorsque ces personnes ne sont pas disponibles et qu'il y a un problème avec il?

Donner aux gens de nouveaux défis les aide à se développer; il se peut aussi que tout le monde n’ait pas la tâche de réviser le code, mais il semble dogmatique d’insister sur le fait que quelqu'un a un titre ( déterminé par la politique et les jeux des ressources humaines ) avant de pouvoir participer à la révision.

Comme d'autres l'ont souligné, la révision du code peut être un processus à double sens; cela aide tout le monde à comprendre la base de code, il partage donc les connaissances, il aide les juniors à apprendre de nouvelles et meilleures méthodes et techniques de leurs aînés et aide les seniors à affiner leur compréhension et en écrivant pour que tout le monde puisse suivre le code attraper des erreurs.


6
Voilà une bonne phrase d'ouverture.
pdr

Si le code utilise des techniques plus avancées (par exemple, en utilisant des opérations sur les ensembles au lieu de tableaux et de boucles), alors ce qui se passe est qu'un membre de l'équipe élève son jeu.
Kevin Cline

1
Lors de la révision de code, il est extrêmement clair que le code nécessite un commentaire ou deux si quelqu'un doit demander ce que fait un code particulier.
Bryan Anderson

24

Les révisions de code ont pour but de détecter les problèmes impossibles à détecter, tels que les problèmes de maintenabilité et les cas critiques. Je dirais que, à bien des égards, les programmeurs débutants conviennent mieux à cette fin:

  • Ils ont plus de temps disponible en général.
  • Ils sont plus susceptibles de le prendre lentement, ligne par ligne, par nécessité de comprendre le code.
  • Lorsque vous parlez de maintenabilité du code, vous entendez tout le monde dans l'entreprise, pas seulement vos meilleurs programmeurs. Cela signifie que vos programmeurs débutants doivent être capables de comprendre le code pour pouvoir le déclarer maintenable.
  • Ils sont souvent moins enclins à faire de mauvaises hypothèses, convaincus que quelque chose fonctionne de la façon dont ils pensent que cela devrait fonctionner.
  • Leur formation dans un langage de programmation est plus récente et moins susceptible d’être confuse avec des années d’expérience dans une autre langue. Par exemple, une personne âgée peut utiliser accidentellement une habitude qu'il a reprise dans C ++ et qui compile mais fonctionne différemment en Java. Les juniors décèlent plus facilement ce type d’erreurs.
  • Les réviseurs de code doivent seulement identifier les problèmes, sans nécessairement proposer une meilleure solution. Ils feront souvent des commentaires dans le sens suivant: "Je ne peux pas vraiment comprendre comment faire mieux, mais cette partie est vraiment déroutante à cause de toutes les répétitions." Un programmeur plus expérimenté peut alors facilement apporter les améliorations même s’il n’a peut-être pas remarqué le problème au début.

Cela ne veut pas dire qu'il n'y a pas d'autres moyens par lesquels les programmeurs expérimentés sont plus aptes à faire des revues, mais ce que je veux dire, c'est que vous ne rendez pas service si vous ne tirez pas pleinement parti de la diversité de votre équipe.


13

On demande souvent aux juniors de maintenir le code, il est essentiel qu'ils puissent le comprendre.

Parfois, les juniors sont les seules personnes disponibles pour consulter le code des développeurs seniors. Le code doit-il attendre avant de passer à QA (nous n'excluons rien de dev sans une révision de code et je suppose également ce type de révision de code) car le patron de la personne âgée est en vacances?

J'ai aussi spécifiquement demandé aux juniors de réviser le code quand je savais qu'ils feraient bientôt quelque chose de similaire pour un client différent ou si je savais qu'ils avaient travaillé sur quelque chose de similaire ou qu'ils avaient des compétences particulières.

Si le code est assez simple, je demande souvent à un junioriste de faire la révision. Pourquoi perdre le temps de la personne âgée si la personne junior est tout à fait capable de faire le travail? Si les juniors se sentent intimidés en examinant le code des seniors, demandez-leur d'abord de regarder les éléments les plus faciles. Après tout, vous ne pouvez pas passer le stade junior avant de cesser de vous sentir intimidé.

J'ai souvent constaté que si je devais expliquer le code à une personne junior qui ne le comprenait pas, je verrais une erreur que j'ai commise (généralement dans une hypothèse) et qu'aucun réviseur de code expérimenté ne l'aurait interceptée car le code était exécuté. mais ne fait pas exactement ce qui était prévu. Ainsi, le simple fait d'expliquer les choses aidera souvent le développeur à voir un problème sans que le réviseur de code le trouve. Etant donné que les personnes plus expérimentées ne sont pas souvent guidées pas à pas dans le code, ces types de choses se trouvent plus facilement quand un junior effectue la révision.

Je trouve que le fait d'avoir junior impliqué dans des revues a plusieurs effets positifs. Premièrement, cela les rend plus confiants quand ils peuvent comprendre le code d’une personne âgée. Cela les rend encore plus confiants quand ils peuvent trouver un bogue dans ce code.

Cela les expose à des processus de pensée extérieurs à la leur et leur permet de voir d'autres façons de gérer les choses. Même en tant que personne âgée, cela m'est arrivé - voir une manière différente de résoudre un problème peut ouvrir les yeux sur de nouvelles possibilités.

Cela les aide à apprendre à lire le code des autres et leur donne l'occasion de demander ce que fait le code alors qu'il est encore frais dans l'esprit de l'auteur. C'est beaucoup mieux que d'avoir à entretenir la chose six mois plus tard, lorsque l'auteur est parti depuis longtemps ou est occupé sur un autre projet et n'a pas le temps de poser des questions.

C'est bon pour les personnes âgées, car les questions exposent à la fois les domaines dans lesquels les jeunes sont faibles et ont besoin de mentorat (afin qu'ils puissent prendre plus de responsabilités et donner plus de temps aux personnes âgées pour effectuer d'autres types de tâches), ou des domaines où le code n'est tout simplement pas clair. n'importe qui sauf l'auteur (ce qui signifie que l'auteur pourrait ne pas l'avoir bien compris dans un an). Cela aide également les seniors à comprendre que les juniors sont peut-être plus intelligents qu'ils ne leur en ont attribué le mérite. Cela aide tout le monde à rester professionnel. Après tout, si vous excluez les juniors, vous impliquez clairement que vous ne pensez pas qu'ils sont capables de comprendre le code qui est psychologiquement malheureux.

Les juniors qui révisent le code des personnes âgées peuvent générer plus de respect professionnel dans votre organisation. Les aînés peuvent se rendre compte qu'ils ont sous-estimé les juniors et les juniors peuvent se rendre compte que les aînés en savent plus qu'ils ne leur en ont crédité. Les juniors pensent parfois qu'ils ont plus de compétences que les leurs. S'exposer au code qu'ils ne peuvent pas écrire est bon pour ces personnes car elles commencent à se rendre compte qu'elles ont beaucoup plus à apprendre. Cela incitera également les meilleurs à acquérir les compétences. Parfois, à l’école, les étudiants B ne comprennent pas pourquoi ils n’ont pas obtenu un A tant que l’on ne leur a pas montré un échantillon du niveau A du travail. Idem pour les juniors aux seniors en révision de code.


7

Ma réponse est: parfois . Cela va varier d'un programmeur à l'autre et d'une tâche à l'autre.

Pour:

  • Si vous voulez que ces juniors apprennent à procéder à une révision efficace du code, le meilleur moyen est de voir comment les seniors le font.
  • Un programmeur débutant peut avoir plus d’expérience qu’un senior dans une langue / un domaine / etc.
  • En obligeant les juniors à évaluer le code des seniors, ils vont inévitablement apprendre des choses. La programmation en binôme constituera un moyen plus efficace de le faire, car toutes les questions des jeunes peuvent obtenir des réponses immédiates.
  • Le code de personne n'est sacré et personne n'est si bon que son code ne devrait pas être revu. Si vous ne le faites pas, qui va revoir le code de vos meilleurs gars?
  • Tous les juniors ne sont pas égaux, et tous les aînés ne sont pas égaux. Parfois, il peut ne pas y avoir beaucoup d’écart, alors ne vous attardez pas sur les intitulés des postes.

Contre:

  • Il y a un risque que les examens s'enlisent avec des problèmes mineurs des juniors.
  • Le niveau de connaissances / compétences requis peut dépasser les capacités du junior. Cela va non seulement leur faire perdre du temps, mais peut-être aussi les démoraliser.

5

Je crois fermement que tous les membres de l'équipe doivent être impliqués des deux côtés de la révision du code. Les juniors doivent revoir le code Senior et vice-versa. Pourquoi les deux? Parce qu'en général, il ne s'agit pas seulement de savoir si le code "résout le problème". Je ne peux pas vous dire combien de fois j'ai dû expliquer un morceau de code à quelqu'un et trouver soudainement un meilleur moyen de le faire avant la fin de l'explication. Les révisions de code ont probablement trois objectifs:

  1. S'assurer que le code est correct
  2. Amenez l'auteur à réfléchir à la manière dont les autres verront leur code
  3. Obtenez les commentaires du lecteur sur ce qui pourrait être amélioré et une deuxième paire d'yeux

Je suis un junior et je révise couramment le code écrit senior. Il s’agit d’une politique générale de la compagnie: "Tout le monde passe le code en revue par quelqu'un". J'apprends beaucoup en passant en revue leur code et en ayant l'occasion de poser des questions sur les raisons pour lesquelles les choses sont faites d'une certaine manière. Et parfois, je propose une manière plus propre de faire un certain morceau de code et autres. Bien plus rare que les gens me disent comment améliorer mon code, mais c'est déjà arrivé au moins une fois.

La révision de votre code est également importante. Les nôtres sont très informels et se composent de "hé, regardez mon code" étant dit à travers des cubicles ou dans un canal privé IRC. J'imagine que si vous examiniez le code dans un contexte plus formel, le débutant serait probablement beaucoup plus intéressé par l'examen du code d'un aîné.


2

Absolument, les ingénieurs débutants devraient examiner le code des ingénieurs seniors, au moins de temps en temps.

D'après mon expérience, il est assez rare que le réviseur lors d'une révision individuelle du code constate effectivement une erreur que le codeur d'origine ignore, que le réviseur soit senior ou junior; le critique n'a même pas besoin d'être humain . En revanche, il est très courant que le codeur original reconnaisse une erreur en essayant d’expliquer le code et que plus le réviseur est novice, plus il est probable qu’elle le soit, en raison de la profondeur de l’explication requise.

À mon avis, certains avantages plus souvent négligés de la révision de code sont peut-être plus importants à long terme que de détecter des erreurs:

  • Partager la connaissance de ce qui se passe réellement dans la base de code - "Attends, je pense que Bill avait une classe qui parle de X, nous n'avons pas besoin d'en écrire un nouveau."
  • Partage des connaissances sur les bonnes techniques et le style de programmation.

Sous ces deux aspects, un examinateur subalterne a tendance à en tirer davantage profit qu'un autre.


2

Les programmeurs débutants doivent absolument effectuer des révisions de code pour leurs collègues plus âgés!

Cependant, ils ne devraient pas être le seul critique . Associez-les à un développeur plus expérimenté lors de la révision du code.

Il y a une myriade d'avantages:

  • L'auteur sera obligé d'expliquer plus de son code. Parler de votre code est l’ un des meilleurs moyens de résoudre les problèmes qui se posent avec lui, ou de meilleures façons de le faire.

  • L'auteur trouvera des faiblesses dans leur code. Le développeur junior est plus susceptible d'être confondu par certains des morceaux les plus avancés. Souvent, ils sont "trop ​​difficiles" pour leur propre bien et pourraient bénéficier d'une simplification.

  • Le développeur junior apprendra de meilleures pratiques de codage. Les revues de code sont une occasion d'enseigner par l'exemple.

  • Le développeur junior sera un réviseur de code plus efficace. La révision de code est difficile . Plus les utilisateurs sont expérimentés avec les révisions de code, plus les révisions de code deviennent rapides et efficaces.

  • Le développeur junior aura une connaissance plus approfondie de la base de code. Être égoïste! En tirant tôt les jeunes développeurs, vous pourrez le leur remettre plus tôt.

  • Le développeur junior se sentira plus impliqué. Le développeur junior va commencer à voir le code "senior" (et ses collègues) comme moins étranger et moins intimidant. Il s'agit d'un avantage considérable et souvent négligé des revues de code.

  • Le junior dev est un regard neuf. Ils ne sont pas aussi endoctrinés que ceux qui travaillent sur la base de code depuis longtemps. Le développeur junior est plus susceptible de signaler différentes manières d'accomplir des choses lorsqu'il pose des questions. Ne négligez pas leurs commentaires plus sauvages sans au moins une certaine considération!

  • Les développeurs seniors sont tenus pour responsables. J'ai souvent vu des situations dans lesquelles les développeurs expérimentés ont tendance à passer sous silence le code de chacun (confiance, paresse, etc.). Une paire d'yeux supplémentaire aide à le décourager.

L'inconvénient à prendre en compte est que toutes les parties concernées consacreront beaucoup de temps à la révision du code. Ainsi, cela peut être un peu difficile à vendre à la direction. Les avantages l'emportent toutefois sur le rythme plus lent.


0

Une révision de code est faite pour réviser le code, pas pour apprendre. Si j'étais un programmeur junior, je serais intimidé de revoir le code de senior.

D'autre part, la lecture du code de la personne âgée est un excellent moyen d'apprendre, à condition que la personne âgée soit disponible pour répondre à toutes les questions.

Deux alternatives pourraient être:

  • permettre aux Juniors d'assister aux réunions de révision du code et laisser chaque intervenant être ouvert à certaines discussions d'enseignement / apprentissage
  • pratiquer la programmation en binôme

7
Les revues de code peuvent être des expériences d'apprentissage. Cela dit, je suis tout à fait d’accord, ce n’est pas leur objectif principal. Idéalement, tous les membres de l'équipe devraient être impliqués, mais je comprends votre point de vue. Il faudra un certain temps avant qu'un développeur (véritablement) junior soit suffisamment confiant pour signaler les défauts (en supposant qu'elle puisse les identifier en premier, ce que je ne voudrais pas non plus. Honnêtement, attendez-vous d’un junior révisant son code).
Yannis

Le PO a explicitement déclaré que le programmeur junior avait de bonnes compétences. Moins d'expérience ne signifie pas toujours des critiques de code de qualité inférieure.
Cascabel

@Jefromi: Le PO a explicitement déclaré qu'il souhaitait définir l'objectif de la révision du code sur apprentissage. Je dis juste que ce n'est pas ce à quoi ils sont destinés.
mouviciel

Hm, je pense que nous comprenons le PO différemment - le message dit qu'il faut mettre l'accent sur l'apprentissage, mais il est également écrit "impliqué en tant que réviseur de code", ce qui implique que le programmeur junior n'est pas la seule personne.
Cascabel
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.