La programmation est un art difficile. Vous êtes un véritable architecte dont la mission est de designer, construire, décorer et entretenir une application, à l’instar d’une maison.

Une difficulté supplémentaire vient s’ajouter à cela : vous devez communiquer avec une machine à travers un langage de programmation. Et il vous arrivera régulièrement de buter sur un problème dont vous ne comprenez pas l’origine. Vous serez persuadés d’avoir bien mis tout en place pour que votre application fonctionne à merveille, mais rien n’y fait : il y a un bug dans votre code.

Le premier réflexe est bien entendu de rejeter la faute sur notre pauvre ordinateur. Après tout, vous savez ce que vous faites, et s’il y a la moindre erreur, c’est cet imbécile d’ordinateur qui fait encore n’importe quoi. Cependant, la vérité est assez cruelle.

La machine fait exactement ce que vous lui dites de faire.

Que vous le vouliez ou non, votre ordinateur est assez bête. Il se contente de récupérer les informations que vous avez tapées et de les exécuter. Et si cela échoue, alors c’est invariablement de votre faute. Oui, c’est assez douloureux à admettre, mais croyez-moi, vous allez vous en remettre.

La balle est donc dans votre camp. Vous savez que vous avez fait quelque chose qu’il ne fallait pas, et pourtant, vous êtes persuadés d’avoir suivi la bonne logique. Alors que faire ? Demander à un collègue ? Chercher des réponses sur StackOverflow ? Non.

La première étape lorsque vous rencontrez une erreur dans votre code est de faire appel au canard.

Je sens déjà vos regards interrogateurs. Un canard ? Vivant ? Donald Duck ou Daffy Duck ?

Ne vous inquiétez pas, je ne vous demanderai pas de partir visiter la ferme la plus proche pour récupérer clandestinement une volaille. Dans notre cas, c’est d’un canard en plastique dont nous aurons besoin.

Une fois votre petit compagnon installé sur votre bureau, il ne vous reste plus qu’à lui parler et à lui expliquer ce que vous essayez de faire avec votre code, et le problème qui vous préoccupe.

Laissez-moi vous rassurer, le canard ne vous répondra pas, il est bien trop occupé avec ses propres affaires. Toutefois, il représente une oreille attentive avec une capacité d’écoute et une patience sans limites contrairement à un collègue. De plus, le canard ne vous jugera pas sur vos erreurs, il est compréhensif.

À force de lui expliquer ce que vous tentez de réaliser et ce que vous avez fait jusqu’à présent, vous allez petit à petit déceler une incohérence entre vos propos et ce résultat souhaité. Doucement mais surement, vous allez enfin mettre le doigt sur la ligne du code qui vous posait problème et que vous pensiez avoir écrite correctement.

Et c’est là l’utilité de la méthode du canard en plastique. En plus de ne déranger aucune personne aux alentours, vous allez vous forcer à prendre du recul sur votre code de manière à pouvoir l’expliquer à une autre personne (ou à un objet dans ce cas-là).

Cet effort de mettre des mots sur le comportement attendu et sur l’exécution de votre code va mettre en évidence des problèmes de conception, des soucis d’optimisation et surtout des erreurs bénignes qu’on ne peut détecter quand on a passé trop de temps le nez dans son code.

En décrivant ce que le code est censé faire et en observant ce qu’il fait réellement, toute incongruité entre ces deux devient évidente.

Ainsi, la prochaine que vous bloquez sur un problème, ne dérangez plus votre collègue, économisez de la bande passante et faites-vous un nouvel ami en parlant à votre canard !

Si vous désirez en apprendre plus sur cette méthode, n’hésitez pas à vous rendre sur le site qui m’a inspiré la rédaction de cet article.

https://rubberduckdebugging.com/

Quand je suis sorti de mon école, j’ai passé plusieurs entretiens pour un poste de développeur. Mes compétences professionnelles se limitant à la réalisation de stages, je m’attendais forcément à ce qu’on teste mes connaissances et mes aptitudes à coder un programme, à répondre à quelques questions techniques ou à résoudre un problème algorithmique. J’avais tort.

Aucun entretien ne m’a testé sur mes compétences de développeur.

J’aurais pu être un charlatan, un vendeur de tapis que j’aurai tout de même obtenu le poste.

Pour être franc, je ne suis pas de ceux qui pensent qu’un questionnaire technique est absolument nécessaire pour détecter si un candidat vaut le coup. Après tout, mieux vaut quelqu’un de motivé, passionné et humainement agréable plutôt qu’une tronche qui ne fait que se plaindre sans arrêt. La technique, ça s’apprend, pas le comportement.

Toutefois, il est quand même nécessaire de détecter le raisonnement d’un candidat face à un problème puisqu’il risque d’être confronté à plus d’un problème durant son travail. Il est donc crucial de s’assurer qu’il soit à la hauteur ou du moins qu’il ait un mode de réflexion qui correspond à ce métier.

C’est là qu’entre en jeu le test du FizzBuzz.

Cet article a été inspiré de la vidéo de Tom Scott que je vous reconseille fortement si le sujet vous intéresse.

https://www.youtube.com/watch?v=QPZ0pIK_wsc

Le principe du FizzBuzz est très simple. Il faut compter à haute voix les nombres en partant de 1. Si vous tombez sur un multiple de 3, au lieu de prononcer le nombre, vous devrez dire “Fizz”. Si vous tombez sur un multiple de 5, vous devrez dire “Buzz”. Et dans le cas où ce serait un multiple de 3 et de 5, il faudrait dire “FizzBuzz”.

Ce problème bien que simpliste au premier abord, à pourtant donné du fil à retordre à de nombreux candidats, certains qui avaient pourtant des années d’expérience dans le métier, comme le démontre l’article de Jeff Atwood sur le sujet.

Essayons ensemble de le résoudre !

Vous pouvez pour cela utiliser le langage de votre choix ou même écrire du pseudo-code. Pour ma part, j’utiliserai Javascript.

Tout d’abord, créons une boucle simple qui bouclera 100 fois sur elle-même.

for (let i = 1; i <= 100; i++) {
  console.log(i);
}

Ainsi, si l’on regarde le résultat, nous aurons la liste de 1 à 100. C’est un bon début ! Reprenons maintenant l’énoncé. Si le nombre est un multiple de 3, alors il faut afficher Fizz, si c’est un multiple de 5 il faut afficher Buzz. Ajoutons donc ces conditions.

for (let i = 1; i <= 100; i++) {
  if (i % 3 === 0) {
    console.log('Fizz');
  }
  if (i % 5 === 0) {
    console.log('Buzz');
  }
  if (i % 3 !== 0 && i % 5 !== 0) {
    console.log(i);
  }
}

Voyons un peu ce que nous avons. Pour tester si le nombre est un multiple de 3, nous utilisons le modulo avec le symbole %. Nous faisons de même avec les nombres multiples de 5. Pour le dernier cas de figure, nous testons que le nombre n’est ni un multiple de 3 ni de 5, et nous affichons ainsi le nombre.

Nous obtenons le bon résultat pour les multiples de 3 et de 5, parfait ! Mais si on y regarde de plus près, il y a un léger souci sur les nombres multiples de 3 et de 5 : Fizz et Buzz ne s’affichent pas sur la même ligne ! Il faut donc prévoir le cas où le nombre est un multiple de ces deux chiffres, et rajouter une condition pour que les deux premiers if ne se déclenchent pas dans ce cas-là.

for (let i = 1; i <= 100; i++) {
  if (i % 3 === 0 && i % 5 !== 0) {
    console.log('Fizz');
  }
  if (i % 5 === 0 && i % 3 !== 0) {
    console.log('Buzz');
  }
  if (i % 3 === 0 && i % 5 === 0) {
    console.log('FizzBuzz');
  }
  if (i % 3 !== 0 && i % 5 !== 0) {
    console.log(i);
  }
}

Cette solution fonctionne ! Mais… Ce n’est pas très compréhensible, vous ne trouvez pas ? Et le code tel quel n’est absolument pas maintenable. Par exemple, que se passerait-il si nous devions changer le code pour que le mot Fizz apparaisse désormais si le nombre est un multiple de 2 ? Il faudrait modifier cette valeur à 4 endroits différents pour faire marcher notre programme.

Cela peut paraître anodin sur un code aussi petit, mais imaginez si vous vous retrouviez à travailler sur un énorme projet. Ce genre de code est propice aux erreurs, complexifie sa maintenabilité et rend presque impossible le développement de nouvelles fonctionnalités.

Essayons donc de revoir notre code sous un autre angle pour fournir une solution plus élégante ! On va d’abord déclarer une variable qui sera notre résultat et qui sera vide. On viendra ensuite lui ajouter Fizz ou/et Buzz si l’on se retrouve dans un des cas particuliers. À la fin, il suffit de tester si notre variable est vide. Si ce n’est pas le cas, on affichera notre variable, sinon nous n’avons qu’à afficher le nombre.

Voici le résultat.

for (let i = 1; i <= 100; i++) {
  let result = '';

  if (i % 3 === 0) { result += 'Fizz'; }
  if (i % 5 === 0) { result += 'Buzz'; }

  console.log(result !== '' ? result : i);
}

C’est déjà beaucoup plus clair ! En plus d’avoir réduit de moitié le nombre de lignes de code, nos vérifications sont uniques et compréhensibles, et permettent d’être modifiées facilement et en ne changeant qu’une seule valeur ! Il est aussi beaucoup plus facile d’ajouter de nouvelles fonctions, par exemple, si on veut afficher “Wozz” pour les multiples de 7, il suffit simplement de rajouter une seule ligne !

On peut donc voir que ce test du FizzBuzz est très intéressant, car en plus de faire appliquer des principes algorithmiques de base à la personne interrogée, il permet entres autres de déceler son mode de raisonnement, la manière dont elle aborde un problème et si elle produit un code qui se soucie de l’avenir.

Pour résumer, FizzBuzz est un problème permettant de faire la différence entre un développeur et un bon développeur.