La meilleure technique de résolution de problèmes en programmation

La résolution de problèmes est ta principale activité en tant que développeur. Devenir bon là-dedans, c’est obligatoire. Heureusement, il existe des techniques bien précises pour ça. C’est exactement ce dont on va parler aujourd’hui.

Prologue

La technique que je vais te présenter est ma façon personnelle de faire. Je l’utilise face aux problèmes de programmation évidemment, mais aussi plus généralement dans la vie quand ça s’applique.

On est pas sur une façon de penser abstraite à la con qui fait aucun sens dans la vie de tous les jours. Cette technique est très concrète. C’est une suite d’actions et d’analyses bien précise. J’arrive à résoudre à peu près tout en assez peu de temps en l’utilisant.

Tu t’imagines bien que je te sors pas magiquement d’un chapeau. Elle est le résultat de deux choses.

• Mon expérience de presque 10 ans en développement devant toutes sortes de problèmes de toutes tailles.
• Les principes intemporels du plus grand livre sur le sujet : How To Solve It.

Ce bouquin est un monument pour notre sujet d’aujourd’hui. Par souci de longueur, il y a beaucoup de choses de ce bouquin que je n’aborde pas. Mais c’est l’une des lectures obligatoires si tu veux vraiment devenir bon en résolution de problèmes.

Pour le moment, sache juste que ce sont des principes intemporels de résolution de problèmes utilisés par des générations de personnes. Mon expérience m’a permis de les tordre correctement pour les faire rentrer dans le monde du développement.

Également, tous les problèmes ne méritent pas toutes ces étapes. Plus ton problème est complexe, plus tu vas utiliser d’actions dans cette technique.

`À toi de faire ton marché dans toutes les actions qui suivent.

Clarifier

Une très grosse partie des problèmes dits complexes sont en fait des problèmes mal compris.

Si tu te lances dans une tâche sans vraiment comprendre ce que tu dois faire, t’as déjà perdu. Je dis ça tout de suite, car que je sais que beaucoup de développeurs font ça. J’ai fait ça pas mal de fois.

Mais y’a pire que ça. Se lancer dans la résolution d’un problème en étant persuadé qu’on l’a compris, alors que pas du tout. C’est bien pire !

Alors, comment faire pour être sûr d’avoir bien compris le problème ?

J’utilise trois actions concrètes :

• Reformulation

Souvent, ton problème est dans une tache écrite à la vite. Celui qui fait la tache est rarement celui qui va faire le travail. Pour lui, pas besoin de tout détailler. Pour toi, c’est absolument crucial.

Il te faut reformuler le problème en une courte explication claire. Si t’es pas capable de faire ça tout seul, tu es pas prêt à commencer. On comprend seulement ce qu’on peut expliquer simplement.

Quelques phrases écrites dans la tache JIRA suffisent largement ici. On ne règle pas encore le problème, on le définit seulement. Crois-moi, ça prend quelques minutes, ça peut te sauver des heures de travail.

• Simplification

Pour la deuxième action, il va s’agir de simplifier, voire réduire, le problème.

Simplifier ton problème en une phrase qui n’aborde que les éléments clefs de ce que tu dois résoudre. Il faut supprimer le bruit et insister sur l’essentiel.

Le but de tout ça est de valider ton raisonnement face à la réalité des choses.

• Validation

Dernière action pour clarifier ton problème, le faire valider par celui qui te l’as posé. Tu envoies un mail/slack/JIRA à cette personne avec la reformulation du problème.

Est-ce que tu peux me valider que c’est bien ça qu’on veut résoudre comme problème ?

De par mon expérience, c’est presque 80% du temps que le problème est partiellement voir entièrement redéfini. C’est ici que tu réduis le plus ton temps de résolution de problème. Oui, avant de commencer.

Mieux que ça, ce n’est pas rare que le problème n’en soit en fait pas un ! Parfois le problème n’est pas là où on croit. Parfois le problème n’existe pas. Il faut la communication de deux corps de métier pour le découvrir.

Toute cette partie est longue à expliquer, pas à appliquer. Tout ça devrait te prendre grand maximum 20/30 minutes. Vraiment maximum !

Si tu es passé tout ça, tu as devant toi un vrai problème clarifié et validé. Maintenant, il te faut un plan.

Planifier

En tant que développeur, on passe que très peu de temps à créer de nouveaux systèmes. La plupart du temps, on lit du code et on modifie un système existant. Ce sont ces systèmes autour du problème qui rendent la tâche complexe.

C’est donc en prenant fortement en compte le système autour du sujet que tu vas faciliter la résolution de ton problème.

Dans ces conditions, il faut donc planifier ce que tu vas faire avant de commencer.

Pour faire ça, je fais deux actions concrètes :

• Schématisation

Papier / stylo, voir tableau blanc quand j’ai en un de dispo, je fais un schéma du contexte de la solution. Je représente visuellement le problème dans son contexte. C’est absolument REDOUTABLE d’efficacité pour la suite.

L’idée ici étant de planifier un premier flow pour une solution en représentant un chemin pour la donnée dans le système.

C’est le moment où tu essayes de penser à tout et à l’afficher en grand pour être sûr de rien rater. Depuis le début de la pandémie, j’ai investi dans un tableau blanc pour faire ça à la maison. Quel plaisir !

Je me répète, mais schématiser rapidement, ça prend quelques minutes, ça peut te faire gagner des heures voir des jours de travail.

• Planification

Maintenant, tu peux planifier ce que tu vas faire. Ici très concrètement, je me fais une liste en mode bullet points de chaque grande étape en me basant sur le schéma.

L’objectif est très simple. Tu ne devrais jamais avoir à te demander : et maintenant je fais quoi ? Ton toi du passé a déjà géré ça.

Appliquer

Maintenant, il est enfin temps de sortir ton éditeur de code et d’écrire la solution.

Tu devrais suivre les grandes étapes logiques qui découlent d’une clarification textuelle et visuelle du problème. Chaque grande étape, prise une par une, devrait alors être décortiquée quand tu codes.

Je distingue deux grandes actions dans cette partie :

• Division

Tu trouveras ce conseil un peu partout, mais j’en rajoute une couche, car c’est bien trop efficace. Il faut diviser chaque problème en sous-problèmes plus simples jusqu’à que tu estimes que ça soit faisable.

Concrètement, tant que tu as devant toi un problème qui te bloque par sa difficulté, n’essaye pas de le résoudre ! Découpe-le en plus petits problèmes plus simples et recommence. Très vite, tu vas tomber devant un problème tout petit et tout simple. Là, tu peux commencer à coder.

Si tu veux creuser ce point en particulier je te conseille fortement cet article de Jérémy Mouzin qui va en profondeur sur le sujet !

• Itération

La seconde action est d’itérer rapidement sur la résolution d’un problème avant de penser à la qualité de la solution.

Concrètement, et en version courte, il faut faire sauter tes blocages et surtout ta paralysie d’analyse devant un probléme.

Pour faire ça, il faut t’autoriser à faire du code rapide et jetable pour prouver la viabilité d’une solution. Une fois que tu as validé que ton problème est vraiment résolu par cette solution, tu gardes le concept, mais cette fois tu fais du beau code.

Pour la version longue, je te l’explique en détail cette partie en vidéo ici :

Cette séquence division/itération dans la partie code est monstrueusement puissante ! Quand j’ai commencé à procéder de cette façon, ça a tout changé. Au fur et à mesure, les problèmes les plus complexes étaient de moins en moins impressionnants.

Malheureusement, je vais être honnête avec toi, j’ai pas réussi à faire tout ça efficacement du jour au lendemain.

Répéter

La résolution de problème est une véritable compétence à part entière.

La bonne nouvelle c’est que, comme toutes compétences, on peut devenir meilleur dedans. La mauvaise nouvelle c’est qu’il faut la travailler pour l’améliorer et/ou la maintenir.

Ça se fait sur le temps et surtout de façon régulière.

Quand j’ai commencé à me préparer pour des entretiens d’embauche importants, j’ai fait comme tout le monde. Je suis allé sur LeetCode pour faire des exercices.

J’ai été absolument terrifié de voir que même certains exercices faciles étaient hors de ma portée. Est-ce que je suis trop bête pour tout ça ?

Et puis j’ai insisté. Encore et encore. Hors de question que je me laisse impressionner.

J’ai remarqué que plus je faisais ces genres d’exo, plus ils étaient simples. Mon impression de ces exercices a alors rapidement changé. Je suis passé du casse-tête infernal à l’énigme drôle à résoudre.

C’est exactement ça que je veux que tu atteignes.

Voir les choses comme des énigmes drôles à résoudre. Quand t’es arrivé là, t’as déjà fait 90% du travail nécessaire. Ton cerveau est entrainé à cette difficulté, la gymnastique a été faite. Les problèmes qui étaient lourds deviennent plus légers.

Une seule action ici : choisis une plateforme gratuite type LeetCode ou HackerRank. Choisis un problème challengeant pour toi et applique la technique que je viens de dérouler dans cet article pour le résoudre.

Fais-le de façon régulière (à toi de décider la fréquence), je te promets des résultats permanents sur la longueur. Notre cerveau n’est pas un muscle, mais il peut être musclé. Je ne connais rien de plus efficace que des exercices réguliers pour faire ça.

Épilogue

Je te promets des résultats immédiats avec cette technique. Tu en auras encore plus sur la longueur. Comme je disais dans le prologue, tu n’as pas forcément de tout pour chaque situation. À toi de choisir le plus optimisé pour ton problème. Si une seule action de tout ça te permet de faire mieux ton travail, j’ai déjà réussi ce que je voulais faire avec cet article.