Coder, ça sert à résoudre des problèmes.
Lorsque je discute avec des personnes qui veulent apprendre à coder, parfois elles oublient ça.
Apprendre à coder, ça n’est pas apprendre un langage. Ni apprendre un framework.
C’est résoudre un problème avec du code que quelqu’un d’autre pourra modifier le jour ou le problème va changer.
(oui j'ai tatoué ça sur mon bras gauche).
Par exemple, sortir d’un labyrinthe, c’est un problème.
Surtout pour celui qui est coincé dedans.
Si je vous donne cette carte, vous allez facilement trouver la sortie.
Dans votre tête, vous allez tracer le bon chemin et le suivre. Là on est sur un problème de niveau "cahier de vacances CP" (celui avec un lapin dessus).
Mais pour une machine ?
Ca parait assez compliqué de coder le truc qui va guider un robot vers la sortie. A chaque croisement marqué par un (?) , comment déterminer le bon chemin ?
Si vous êtes développeur, vous savez combien c’est un problème simple à résoudre.
Le fait d’être un maestro en ReactJS ou en Scala ne change rien. Ce qui change tout, c’est de se représenter le labyrinthe par un graphe dont chaque noeud comporte la distance à la sortie.
Dans le cerveau (parfois brumeux) du développeur, il se passe ça :
Un sudoku ?
Mais non, pas du tout. Un graphe.
En partant de la sortie, vous savez calculer le nombre de cases qui vous séparent du but. On appelle ce nombre le "coût". Il évalue à quel point on est mal (= loin de la sortie).
Trouver le meilleur chemin consiste simplement à suivre la pente décroissante du coût. Ou suivre le chemin qui fait le moins mal.
Arrivé à la case 18, je sais qu’en prenant à gauche vers la case 17 je vais diminuer le coût. C'est donc le bon chemin vers la sortie. Et plus globalement, quelle que soit sa position dans le labyrinthe, un robot trouvera facilement le plus court chemin vers la sortie grâce à cette astuce.
Résoudre un problème avec du code, c'est construire une représentation du problème facile à résoudre par une machine.
On fait pivoter le problème dans sa tête comme un rubik’s cube. Jusqu’à trouver une façon particulière de le décrire pour coder sa résolution.
L’autre point intéressant, c’est qu’on part de la sortie.
Au lieu d’avancer, recule la sortie.
Notre carte résolue du labyrinthe est numérotée à partir de la sortie. On calcule à chaque case la distance qui nous sépare de la sortie en reculant d’un pas.
C’est un schéma de pensée intéressant et singulier.
D’habitude, lorsqu’on cuisine un plat ou que l’on construit une maison, on avance. Par étape. En suivant le plan.
Mais pour construire un logiciel, on s’y prend d’une autre manière : on va en marche arrière !
On part de quelque chose de très simple qui fonctionne (tout près de la sortie, ou de StackOverflow). Puis on augmente progressivement la distance qui nous sépare de ce qui fonctionne. Et ainsi de suite jusqu’à rejoindre le départ.
Cette méthode présente un avantage de taille : quel que soit l’avancement du projet, il y a toujours quelque chose qui fonctionne !
Alors bien sûr, au début, on est loin des fonctionnalités attendues. D’ailleurs, on ne les connaît pas toutes.
Mais le code est toujours prêt à être mis en production. Il peut être confronté aux attentes des utilisateurs, dans un contexte réaliste.
Alors on fait l’économie des réunions de chantiers
"Bon les devs, ou en est-on sur le projet ?"
– Bob, le chef de projet
Pour connaître l’avancement, lance l’appli.
