Pour déboguer leur code, les développeurs utilisent parfois le "Rubberducking" ou "Méthode du canard en plastique". Elle consiste tout simplement à expliquer en détail et à voix haute chaque étape du code à un canard en plastique, ce qui permet souvent de repérer des erreurs. Technique utilisée d'ailleurs chez SCMB !
La méthode fonctionne évidemment avec n'importe quel interlocuteur, mais un objet inanimé est en général plus patient qu'un collègue.
Commentaires préférés (3)
Plutôt que de réfléchir dans ta tête, tu réfléchis à autre voix en expliquant à un objet. Ça permet de se mieux se rendre compte des bêtises qu’on est en train de faire ou d’écrire dans son code
Un peu dans le même genre, les conducteurs de trains Japonais pointent du doigt et confirment oralement les signaux rencontrés sur la ligne, pour éviter toute erreur.
«Technique utilisée d'ailleurs chez SCMB !»
Ben le canard ne vous a jamais expliqué les problèmes
_1) des déconnexions sauvages et permanentes,
_2) des difficultés lors des tentatives de connexions (6 ou 7 pour se connecter n'est pas exceptionnel), quand tu n'es pas renvoyé sur une page "erreur 405"
_3) du chat qui te dit que ton com avec 3 liens, 2 citations et 18 lignes de texte vient de disparaitre pour toujours... (j'en suis arrivé à faire un "copié" avant de poster chaque commentaire)...
_4) du site subitement inaccessible pendant de longues minutes à n'importe quel moment du jour ou de la nuit?
Si ce canard ne vous a jamais parlé de tout ça (et j'en oublie), virez-le et n'hésitez pas à en acheter un neuf
Tous les commentaires (24)
Ce n’est pas forcément à un canard en plastique maintenant. On a d’ailleurs de belles expositions de différents objets/jouets sur les bureaux des développeurs!
Bientôt fini avec l’IA qui code à tour de bras ? Vrai sujet.
Attention, pour suivre la "hype de l'IA", beaucoup de fabricants/vendeurs nous en mettent dans tout et n'importe quoi. Mais en fait c'est encore souvent des algorithmes, et non pas de l'IA !
Donc non ce n'est probablement pas de l'IA dans votre aspirateur, tondeuse, four, brosse à dents, etc etc.
J’ai rien compris !!!
Plutôt que de réfléchir dans ta tête, tu réfléchis à autre voix en expliquant à un objet. Ça permet de se mieux se rendre compte des bêtises qu’on est en train de faire ou d’écrire dans son code
C'est très efficace! Faire l'effort de formuler clairement avec une phrase son problème, le contexte, etc. permet souvent de se remettre les idées en place et trouver la solution. Ça marche aussi quand on commence à écrire un message au collègue
Un peu dans le même genre, les conducteurs de trains Japonais pointent du doigt et confirment oralement les signaux rencontrés sur la ligne, pour éviter toute erreur.
La meilleure façon de savoir si un code est correct, c'est pas tout simplement de le tester ?
(Et donc de considérer que tout ce qui n'est pas testé ne fonctionne pas.)
Le but n'est pas de savoir si ça fonctionne mais plutôt de comprendre pourquoi ça ne fonctionne pas.
Franchement l'informatique redécouvre l'eau tiède régulièrement en posant des concepts ( et des noms incompréhensibles) sur des choses tellements basiques. On appelle ça, raisonner a haute voix sinon.
Allez, et puis je vais aller au toilette pratiquer le yellowflowing. Vieille technique de pause entre 2 lignes de code.
Se rendre compte qu'il y a un problème c'est souvent l'étape la plus facile, même si certains bugs ne se déclenchent que selon certaines conditions bien précises ou à l'inverse de façon pseudo aléatoire (ceux-là sont particulièrement pénibles à pister).
Une fois qu'on se rend compte qu'un truc ne marche pas, il faut ensuite trouver pourquoi, et là c'est une autre paire de manches. C'est facile de se rendre compte qu'une voiture fait un bruit bizarre, c'est autre chose d'arriver à en trouver la cause.
Dans le cas d'un bug dans votre programme informatique la bonne nouvelle c'est que, contrairement à la voiture, c'est à priori vous qui l'avez fabriqué, et donc que 1 C'est votre faute si un truc ne marche pas. 2 Vous êtes capables de corriger le problème.
Parfois le bug vient juste d'une bête erreur de syntaxe, la moindre virgule mal placée pouvant être fatale en informatique. Par exemple écrire "<" ou lieu de ">", ou encore écrire (i > 0 && i*(n+1 < 10)) au lieu de (i > 0 && i*(n+1) < 10). Si vous ne voyez pas la différence entre les deux dernières expressions je vous invite à prêter attention aux parenthèses, j'ai déjà perdu un temps fou à cause d'une erreur du genre.
Parfois en revanche il ne s'agit pas d'une simple faute de frappe mais d'un problème de logique dans la façon dont on a programmé notre truc. En grossissant le trait on pourrait imaginer une voiture où, au moment du montage, on aurait pas raccordé les tuyaux dans le bon ordre. Sauf que là les tuyaux c'est des bouts de codes plus ou moins complexes et abstraits. Il faut donc reprendre le raisonnement de notre programmation étape par étape, pour voir à quel moment est-ce qu'on a fait quelque chose qui ne faisait pas sens. Sauf qu'en étant absorbé dans ses lignes de codes et en les relisant en boucle sans voir ce qui coince on finit parfois par tourner en rond alors qu'exprimer clairement la logique de ce qu'on lit point par point est parfois beaucoup plus efficace. Je ne compte pas le nombre de fois où, après avoir passé de longues minutes à essayer de trouver ce qui clochait en vain, j'ai commencé à râler auprès de quelqu'un en mode "Mais c'est pas possible enfin ! Ça fait machin et puis après ça fait truc, du coup logiquement après ça devrait faire chose... ha mais non attends en fait pas du tout, quel imbécile !"
En général quand tu as besoin de réfléchir à haute voix, c'est que t'as déjà essayé les autres options.
Et l'IA c'est un outil, pour le moment c'est encore incapable de créer un programme complexe sans développeur derrière (même si on peut réussir à faire des trucs sans coder nous même, il faut superviser). C'est un peu un stagiaire qui est très bon techniquement mais qui n'a aucune autonomie.
Le développement se fait en plusieurs étapes. L'approche la plus courante: d’abord, le programmeur teste son code sur sa propre machine. Ensuite, un autre développeur le vérifie. Le changement est ensuite intégré au code principal, puis testé par un testeur ou un système automatisé. Enfin, l’utilisateur vérifie que tout fonctionne toujours correctement, en plus du nouveau changement. La différence est que le développeur verifie uniquement que son code fonctionne, alors que les testeurs vérifient aussi qu'aucun scénario ne cause de problème. Par exemple, un nouveau bouton est ajouté au site. Le développeur verifie que le bouton fonctionne et donne le résultat escompté. Le testeur va verifier que si on clique le bouton plusieurs fois, rien ne casse.
«Technique utilisée d'ailleurs chez SCMB !»
Ben le canard ne vous a jamais expliqué les problèmes
_1) des déconnexions sauvages et permanentes,
_2) des difficultés lors des tentatives de connexions (6 ou 7 pour se connecter n'est pas exceptionnel), quand tu n'es pas renvoyé sur une page "erreur 405"
_3) du chat qui te dit que ton com avec 3 liens, 2 citations et 18 lignes de texte vient de disparaitre pour toujours... (j'en suis arrivé à faire un "copié" avant de poster chaque commentaire)...
_4) du site subitement inaccessible pendant de longues minutes à n'importe quel moment du jour ou de la nuit?
Si ce canard ne vous a jamais parlé de tout ça (et j'en oublie), virez-le et n'hésitez pas à en acheter un neuf
La page Wikipedia donne plus de détails.
fr.wikipedia.org/wiki/M%C3%A9thode_du_canard_en_plastique
Et pour la petite histoire, quand cela arrive qu'un collègue se rend compte de son erreur en m'expliquant sans que je n'ai pas vraiment besoin de l'aider, sa arrive souvent que je lui dise: "tu me prend pour un canard en plastique !?!"
J'allais également mettre un commentaire salé.
Depuis la refonte c'est une catastrophe. On a perdu le simple fait de pouvoir swiper d'anecdote en anecdote, les coms qui mettent 10 ans à charger...
Quand bien même on trouve effectivement souvent tout seul d'où vient le souci en exposant les choses à ses collègues, il n'empêche que des fois ce sont eux qui mettent le doigt sur l'erreur de code ! Mon canard, il ne met aucun doigt nulle part ! (ni mon Mario, ni mon Link, ni mon Sangoku, ni mon burger du BurgerQuizz)
En tant que dev, je le fais souvent. D’ailleurs j’aime bien exposer mon problème à l’IA, le semble fait de l’écrire me fait réfléchir à ce qui en va pas et trouver plus facilement la réponse, avant même d’envoyer le message.
Étant conducteur de train cela nous est imposé par bon nombre de formateur, et donc la plus part de mes collègues, moi y compris appliquons cette méthode de bouclage.
La seule difference étant; de 1, nous somme moins visible que nos collègues japonnais et de 2, culturellement, notre manque de rigueur sur la durée.