Mais je ne partage pas son avis, le code review c'est pas que voir des bug, c'est aussi une façon pour les nouveau d'apprendre et découvrir le projet, c'est aussi de saines questions sur des trucs qui nous paraissaient évident mais qui après remise en question moins.
Alors on peut avoir ces input par du pair programming, mais c'est plus compliqué à organiser, et on a aussi besoin de son espace vital qui fait qu'on ne peut pas être en pair sur toute la journée de travail.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
La base de l'argument semble quand même intéressante. Si tu demandes à un nouvel arrivant de relire du code, et que c'est seulement à ce moment là qu'il pose une question sur un truc qui semblait évident, tu viens probablement de détecter un problème de documentation, ou d'onboarding par exemple. Et tu vas sûrement le corriger pour que le prochain nouveau ne pose pas la même question.
Je me garderai bien d'avoir un avis sur comment remplacer ce processus de revue par quelque chose introduisant moins de latence dans un contexte de développement assisté/augmenté par des LLM qui est ce que semble chercher l'auteur.
Par contre je pense que ça met le doigt sur la bonne explication et valorisation du processus de revue: ça détecte les problèmes assez tard, donc à un moment où ils coûtent cher à corriger. Et donc, c'est intéressant surtout si on en profite pour éliminer non seulement le problème immédiat, mais aussi ses manifestations futures. Que ça soit en mettant en place de nouveaux outils (de formatage de cude par exemple), en améliorant la documentation, en faisant monter en compétence les personnes concernées sur un point difficile du langage de programmation (oui, je fais du C++), en améliorant la façon dont on rédige les spécifications ou les user stories, ou parfois avec des questionnements plus vastes sur l'architecture, les technologies choisies, le processus de déâeloppement en lui-même, …
Et c'est quelque chose qui n'est pas forcément bien compris par tout le monde, et qu'il faut expliquer ou parfois même défendre. Car, effectivement, à première vue, on irait 10 fois plus vite sans relecture de code.
# c'est intéressant
Posté par fearan . Évalué à 4 (+1/-0).
Mais je ne partage pas son avis, le code review c'est pas que voir des bug, c'est aussi une façon pour les nouveau d'apprendre et découvrir le projet, c'est aussi de saines questions sur des trucs qui nous paraissaient évident mais qui après remise en question moins.
Alors on peut avoir ces input par du pair programming, mais c'est plus compliqué à organiser, et on a aussi besoin de son espace vital qui fait qu'on ne peut pas être en pair sur toute la journée de travail.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: c'est intéressant
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Euh, si le nouveau en question arrive à apprendre le métier en relisant le vomi d'un générateur approximatif de code, on est pas tiré d'affaire…
[^] # Re: c'est intéressant
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
La base de l'argument semble quand même intéressante. Si tu demandes à un nouvel arrivant de relire du code, et que c'est seulement à ce moment là qu'il pose une question sur un truc qui semblait évident, tu viens probablement de détecter un problème de documentation, ou d'onboarding par exemple. Et tu vas sûrement le corriger pour que le prochain nouveau ne pose pas la même question.
Je me garderai bien d'avoir un avis sur comment remplacer ce processus de revue par quelque chose introduisant moins de latence dans un contexte de développement assisté/augmenté par des LLM qui est ce que semble chercher l'auteur.
Par contre je pense que ça met le doigt sur la bonne explication et valorisation du processus de revue: ça détecte les problèmes assez tard, donc à un moment où ils coûtent cher à corriger. Et donc, c'est intéressant surtout si on en profite pour éliminer non seulement le problème immédiat, mais aussi ses manifestations futures. Que ça soit en mettant en place de nouveaux outils (de formatage de cude par exemple), en améliorant la documentation, en faisant monter en compétence les personnes concernées sur un point difficile du langage de programmation (oui, je fais du C++), en améliorant la façon dont on rédige les spécifications ou les user stories, ou parfois avec des questionnements plus vastes sur l'architecture, les technologies choisies, le processus de déâeloppement en lui-même, …
Et c'est quelque chose qui n'est pas forcément bien compris par tout le monde, et qu'il faut expliquer ou parfois même défendre. Car, effectivement, à première vue, on irait 10 fois plus vite sans relecture de code.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.