Réponse courte
Dois-je réparer le code moi-même?
Non.
Dois-je leur faire part de leurs commentaires sur le processus de révision et les laisser effectuer les corrections conformément à mes instructions?
Oui. Selon vos suggestions , pas les instructions . Les instructions semblent trop autoritaires.
Et si oui, comment puis-je donner cette rétroaction, dois-je remplir certains documents de modèle et les envoyer à eux, ou il existe un logiciel qui m'aidera à marquer les choses avec des problèmes dans les fichiers de code où ils pourront plus tard le vérifier? (J'utilise Visual Studio).
Utilisez un outil pour donner votre avis. Vous pouvez utiliser Visual Studio.
Longue réponse
J'utilisais Visual Studio mais je devais constamment demander à d'autres développeurs: "Hé, pouvez-vous m'envoyer votre travail pour que je puisse le revoir?" Je n'aimais pas ça et ça n'a jamais vraiment bien marché. Maintenant, j'utilise l' assistant d'examen car je peux commencer un examen en consultant les enregistrements. Je n'ai pas besoin de me fier à un autre développeur pour m'envoyer du travail à réviser. Cela m'aide également à marquer les éléments comme des défauts, ou simplement à marquer les éléments à regarder par l'auteur. Cela fonctionne pour notre équipe car une fois que nous commençons une révision, elle reste là sur le tableau de révision et ne se perd pas dans la traduction. Ceci est intégré à Visual Studio. Comme je l'ai mentionné, Visual Studio a également son processus de révision natif mais je trouve qu'il a des limites et le processus n'est pas naturel; par conséquent, j'utilise Review Assistant.
Cet outil facilite également les allers-retours, les discussions, etc.
Le processus est plus ou moins le suivant:
Je passe en revue quelque chose, puis je l'envoie à l'auteur (dans votre cas junior dev). Ils apportent des modifications, puis ils le renvoient. J'examine les changements et je fais des commentaires. Si je suis bon avec les changements, je ferme l'examen. Sinon, ça va et vient. Parfois, s'il y a trop de va-et-vient, je vais simplement me diriger vers leur bureau et utiliser un tableau blanc - cela accélère vraiment le processus.
Les révisions de code sont un domaine sensible, alors soyez très prudent avec le choix du libellé. Je ne dis jamais à personne
Mauvais choix de formulation
J'ai examiné votre code et vous devez modifier certains éléments.
Je dis plutôt ceci:
Meilleur choix de formulation
J'ai regardé votre code et j'ai besoin d'aide. Pouvez-vous revoir les articles que je vous ai envoyés et voir si vous pouvez clarifier certaines de mes questions?
Cela fait penser à l'auteur:
- J'ai besoin d'aide pour qu'ils ne passent pas en mode défensif.
- On dirait qu'ils sont le critique, pas moi. Techniquement parlant, puisque je leur demande de revoir et de changer certaines choses, ils sont en quelque sorte comme le critique.
Ces choix de mots simples m'ont énormément aidé.
Je ne sous-estime jamais les développeurs juniors. J'ai travaillé avec des développeurs seniors (plus de 10 ans d'expérience) et le code était pire qu'un étudiant coop junior. Ce n'est donc pas si important parce qu'ils sont seniors ou juniors; leur travail est vraiment ce qui parle plus fort que des années d'expérience.
Souvent, pour encourager les développeurs juniors et les faire participer aux revues, je leur enverrai quelque chose à réviser pour moi: quelque chose qu'ils peuvent comprendre, quelque chose qu'ils trouveront difficile mais pas totalement au-delà d'eux. Je peux le dire comme ci-dessous:
Pouvez-vous s'il vous plaît examiner un code pour moi parce que je ne peux pas le comprendre.
Cela m'aide beaucoup à nouveau. Cela aide parce que cela montre clairement que je ne suis pas le seul à réviser, mais ils font également des révisions et ils font également partie du processus. Cela montre que l'idée est de produire un bon code propre et de demander de l'aide si nécessaire. Le processus d'examen est une culture, nous devons donc vraiment y travailler.
Maintenant, certaines personnes peuvent craindre que si elles font ce qui précède, les développeurs juniors perdront leur respect parce qu'ils ont juste fait quelque chose que vous ne pouviez pas faire. Mais c'est loin de la vérité: demander de l'aide montre de l'humilité. De plus, il existe de nombreuses situations dans lesquelles vous pouvez briller. Enfin, si telle est votre peur, vous avez des problèmes d'estime de soi. Enfin, peut-être que je ne le sais vraiment pas: je veux dire que certains de ces développeurs ont des algorithmes frais dans leur tête parce qu'ils les ont étudiés il y a un mois.
Quoi qu'il en soit, retour aux juniors et critiques. Vous devriez voir le regard sur leurs visages quand ils le découvriront et m'enverront une réponse. Je peux alors leur dire: "OK, laissez-moi faire les changements et si vous en êtes satisfait, veuillez fermer le problème."
Ils se sentent super d'avoir le pouvoir de regarder mon travail et de dire: "Oui, vos changements sont bons. J'ai clos le problème."
Je ne corrige jamais le code moi-même car:
- L'auteur n'en tirera aucune leçon.
- C'est comme si je disais: "Écarte-toi, laisse-moi te montrer comment c'est fait. Mon code est meilleur que le tien."
- Pourquoi aurais-je? C'est plus de travail pour moi.
Mais je proposerai des idées et des extraits de code dans mes commentaires pour aider l'auteur. Veuillez noter que parfois mes critiques demandent simplement à l'auteur que je ne comprends pas leur code; il n'y a peut-être rien de mal avec leur code. Ils peuvent avoir besoin de changer les noms des variables, d'ajouter des commentaires, etc. Ainsi, je ne saurai même pas quoi changer dans ce cas; seulement ils le feront.
Si vous continuez à faire des révisions, vous aurez tôt ou tard une très bonne idée du niveau de connaissance de chaque développeur de l'équipe. Le savoir est vraiment utile et vous devez en profiter et le libérer. Voici comment: si je passe en revue du code et que je vois des domaines d'amélioration évidents et que je sais qu'un autre développeur peut également les attraper, je les ferai le réviser à la place. Quelque chose comme "Hé, je vois quelques domaines qui peuvent être améliorés. Pouvez-vous s'il vous plaît l'examiner plus en détail et envoyer vos commentaires à l'auteur?" Cela fonctionne aussi très bien car maintenant j'ai 2 autres développeurs qui travaillent ensemble.
Si je passe en revue certains travaux et que je remarque quelque chose dont toute l'équipe peut bénéficier, je vais créer un scénario hypothétique et expliquer le problème lors d'une réunion. Je vais commencer par expliquer le scénario et demander à tout le monde s'ils peuvent trouver le problème ou voir un problème, les impliquer. Demandez à tout le monde de poser des questions. Enfin, présentez une meilleure approche. Si quelqu'un d'autre a une meilleure approche, je les remercie et je reconnais devant l'équipe que leur approche est meilleure. Cela montre que je ne suis pas un type de personnalité «à ma façon ou sur l'autoroute». De plus, je n'ouvre JAMAIS le travail de quelqu'un et je commence à souligner les problèmes lors d'une réunion, l'auteur ne l'appréciera pas - peu importe à quel point je suis gentil et inoffensif.
Quand je fais des revues, je ne cherche pas seulement un bon code propre mais aussi ce que fait le code. Si l'exigence commerciale est la suivante: si un employé travaille dans l'entreprise depuis plus de 10 ans, accordez-lui une augmentation de 5%. Sinon, 2,5% . La première chose que je vérifie est de savoir si c'est effectivement le cas. Ensuite, je vérifie s'il le fait de manière propre, cohérente et performante.
Si je fais un examen, je m'assure de faire un suivi ou personne ne prendra les examens au sérieux.
Il y a des années, je travaillais avec quelqu'un qui ferait une revue et ferait un cc au responsable du développement et au responsable de l'assurance qualité, mais les deux managers venaient d'un milieu commercial ou avaient peu d'expérience en développement. Il n'a fait cela que pour les impressionner. Personne n'a aimé et c'est à ce moment-là que je me suis dit que je ne ferais jamais cette erreur.
L'autre chose qu'il avait l'habitude de faire était de choisir le style de programmation et était convaincu que son style était le meilleur ("Mon kungfu est bien meilleur que votre style singe ..."). C'était une autre leçon pour moi: il y a toujours plus d'une façon de résoudre un problème.
Répondez à certaines de vos questions numérotées
1- Dois-je réparer le code moi-même?
Non, veuillez consulter les raisons que j'ai mentionnées ci-dessus.
2- Dois-je leur donner des commentaires sur le processus de révision et les laisser faire les corrections selon mes instructions?
Oui, essayez d'utiliser des phrases et un ton amical mais qui nécessitent encore de l'attention. Soyez aussi clair que possible. Indiquez quel est le problème avec le code, comment l'améliorer. Ne demandez pas simplement de le changer. Mais donnez des raisons.
comment puis-je donner cette rétroaction, dois-je remplir certains documents de modèle et les envoyer à eux, ou il existe un logiciel qui m'aidera à marquer les choses avec des problèmes dans les fichiers de code où ils pourront plus tard le vérifier? (J'utilise Visual Studio).
Comme je l'ai dit, vous pouvez utiliser l'outil que j'utilise ou un autre outil. N'utilisez pas de documents électroniques ou Word car ils se perdent et il est difficile de les suivre.
Après avoir passé en revue le code et les correctifs, puis un certain temps s'est écoulé et certaines parties du code que j'ai examiné dans le passé ont changé, comment dois-je procéder pour réexaminer le code? dois-je revérifier tout le code?
La plupart du temps, je vérifie le delta (modifications uniquement). Mais vous devez avoir une vue d'ensemble pour vous assurer que rien n'est cassé et qu'il suit l'architecture.
Dernières pensées
Personnellement, je pense que le mot «révision de code» est un mauvais choix et je ne sais pas comment il a commencé. Ils auraient pu choisir un mot bien meilleur et moins autoritaire.