La méthode du rubber duck debugging ou l’art de résoudre un problème quand on est programmeur

Par Done Technologies

Lorsque vous écrivez du code pour un logiciel, s’il y a bien une chose dont un programmeur est certain, c’est qu’à un moment donné il se retrouvera bloqué. Ce genre de situation arrive tout le temps et n’importe quel programmeur pourra vous le confirmer. Peu importe votre expérience que vous soyez débutant ou vétéran, vous vous retrouverez dans une impasse avec un problème de programmation que vous ne pourrez pas résoudre dans l’immédiat. Dans ce genre de situation, la question qu’il faut se poser est la suivante : comment résoudre le problème? L’une des techniques les plus populaires s’appelle la méthodologie du canard en plastique ou Rubber Duck Debugging en anglais.

pourquoi le canard en plastique ?

On doit l’idée de parler à un canard en plastique au livre The Pragmatic Programmer: From journeyman to Master de Andrew Hunt et David Thomas, dans lequel un étudiant explique son code ligne par ligne à un canard en plastique pour déboguer plus facilement.

Depuis la publication de ce livre, il est très commun de voir ce petit animal en plastique sur les bureaux des programmeurs, à tel point qu’avec le temps il est devenu une figurine iconique dans l’univers des programmeurs et développeurs. L’utilisation du canard en plastique permet de reproduire le même exercice (sans avoir à déranger un de vos collègues), en plus d’offrir une attention et une écoute illimitée.

Qu’est-ce que la technique du Rubber Duck Debugging?

La méthode du canard en plastique, aussi appelé « rubber duck debugging » ou « rubber ducking », consiste à expliquer à un canard en plastique un problème de programmation de manière méticuleuse et à haute voix. Cet exercice permet de mettre en lumière les incohérences et de résoudre le problème de programmation.

Prenons l’exemple suivant. Vous écrivez un algorithme et votre ligne de code ne fonctionne pas. Le morceau de code que vous venez d’écrire présente une incohérence et ne répond pas de la manière que vous l’auriez imaginé. Que faites-vous? Vous essayez de trouver une solution par vous-même, sans trop de succès. Puis, vous vous levez de votre bureau, vous allez voir votre ami-collègue qui est aussi programmeur pour la même entreprise et vous commencez à lui expliquer votre problème afin qu’il puisse vous aider. Vous lui expliquez ce sur quoi vous travaillez et puis d’un seul coup, ça vous frappe, la solution vous saute aux yeux!

« Vous avez déjà tous entendu la réplique : se poser la question c’est y répondre. C’est encore plus vrai quand on essaie d’expliquer notre code. Lorsqu’une personne vous explique son code et vous dit quelque chose comme “ne fait pas attention à ça, c’est juste pour que ça marche en attendant…” ou “cette méthode est censée faire telle ou telle chose”, il y a de fortes chances que cela cache un problème. Autre exemple, lorsque l’on vous dit : “Ce bout-là je ne sais pas trop ce que ça fait alors je n’y ai pas touché”, ça, c’est un gros drapeau rouge. Ne prenez pas pour acquis que ce l’on vous dit est vrai, il faut impérativement toujours vérifier. »

Aussi simples que cela puisse paraître, il est très fréquent pour des programmeurs de se retrouver dans ce genre de situation : ils font face à une incohérence dans leur code, vont chercher de l’aide et la solution leur apparaît tout à coup. Le simple fait d’exprimer à haute voix votre problème et d’en parler à un collègue peut vous aider à résoudre la situation problématique. C’est ce que l’on appelle la méthode du canard en plastique.

Pourquoi la méthode du Rubber Duck Debugging fonctionne-t-elle ?

La raison est simple, quand vous expliquez votre situation à quelqu’un d’autre ou en l’occurrence à un canard en plastique, vous êtes obligé d’expliquer de manière détaillée le problème à votre interlocuteur. Vous lui expliquez le contexte, chacune des étapes et lignes de code pour enfin arriver à détailler votre problème. C’est en faisant ce processus que la solution vous apparaît de manière logique. En d’autres termes, ce que vous venez de faire, c’est de prendre une pause, faire un pas de recul et vous vous êtes repassé le film dans votre tête.

En agissant de la sorte, vous visualisez mieux la situation. Quand vous expliquer votre problème à un canard en plastique, ce dernier ne connait absolument rien au code (c’est un canard) et donc vous devez lui détailler votre problème, le mettre en contexte. Et c’est ainsi qu’en expliquant votre projet depuis le début dans les moindres détails, en allant étape par étape, jusqu’à la situation problématique, que vous trouverez par vous-même la réponse à votre problème. Lorsque nous travaillons plusieurs heures sur un même projet, nous avons tendance à être trop « impliqué » et lorsqu’un problème ou une incohérence apparaît, toute notre attention est portée dessus. En prenant un pas de recul, la solution devient plus évidente.

Vous avez des problèmes qui nécessitent de l’aide ou des conseils ? Notre service d’accompagnement d’architecture logiciel vous aidera dans vos projets. Il s’agit en quelque sorte d’un service de Rubber Duck Debugging en ligne avec une équipe d’experts à votre disposition.

Autres articles qui pourraient vous intéresser

Custom Software Development | Done Technologies

Segmenter pour la pérennité

Vous devez ajouter des fonctionnalités dans un vieux langage? Pourquoi ne pas sortir des sentiers battus?! Bien sûr, il est toujours agréable de démarrer un nouveau projet. On choisit l’architecture et les technologies tout en tenant compte des besoins actuels et futurs du client. Cependant, ce ne sont pas tous les projets pour lesquels on...
Explorer et innover au sein de notre laboratoire | Done Technologies

5 astuces pour éviter les dépassements de coûts liés à votre développement logiciel

Qu’il s’agisse de supprimer une tâche récurrente, gagner en productivité et en efficacité, les entreprises se tournent davantage vers la technologie pour subvenir à des besoins précis. Alors qu’il existe sur le marché une pléthore de logiciels favorisant la gestion de la paie, la communication au sein de différentes unités d’affaires ou encore l’automatisation du marketing,...

Imaginez un monde où le passé est la seule vérité… toute la vérité

Vos systèmes informatiques contiennent sûrement plusieurs bases de données structurées et relationnelles. Vous devez faire des copies régulièrement pour ne pas perdre d’information. Malgré ces précautions, vous perdez tous les états intermédiaires (états du système après un événement passé) de vos systèmes d’information. Si tout ce qui vous intéresse, c’est l’état final, ce n’est pas...