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.
[^] # Re: c'est intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Whoa, I produced this prototype so fast! I have super powers!. É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.