Tu connais maintenant les briques de base, les variables, les types, les conditions, les boucles, les fonctions, la récursivité et les objets. Mais dans la vraie vie, un développeur ne te montre pas une brique à la fois. Il te montre un écran avec des dizaines de lignes qui combinent tout ça. Voyons comment s'y retrouver.
On ne lit pas du code comme un livre
Un livre se lit de haut en bas, du début à la fin. Le code, non. L'exécution saute d'un endroit à un autre : une
fonction en appelle une deuxième, qui en appelle une troisième, qui retourne un résultat à la première. Le code
est organisé comme un réseau, pas comme une ligne droite.
Bonne nouvelle, tu n'as pas besoin de suivre chaque saut. Tu as juste besoin de comprendre l'intention générale.
Et pour ça, tout repose sur une seule chose, les noms.
Les noms racontent l'histoire
Regarde ce bout de code sans essayer de comprendre la syntaxe :
function envoyerRappelAbonnement(client) {
if (client.estAbonne() && client.abonnementExpireBientot()) {
let message = creerEmailDeRappel(client)
envoyerEmail(client.email, message)
}
}
Même sans connaître JavaScript, tu comprends ce que fait ce code. Si le client est abonné et que son abonnement
expire bientôt, on crée un email de rappel et on l'envoie. Les noms des fonctions et des variables suffisent
à comprendre la logique.
C'est pour ça que les développeurs passent autant de temps à bien nommer les choses. Un code bien nommé se lit
presque comme une phrase.
L'abstraction : ne pas ouvrir chaque boîte
Dans l'exemple ci-dessus, la fonction envoyerEmail fait probablement un tas de choses complexes :
se connecter à un serveur, formater le message, gérer les erreurs de livraison... Mais tu n'as pas besoin de le
savoir pour comprendre ce que fait envoyerRappelAbonnement.
C'est le principe de l'abstraction, qui consiste à cacher la complexité derrière un nom clair. Tu appuies sur un interrupteur
pour allumer la lumière sans comprendre comment fonctionne le circuit électrique. Tu tournes la clé de ta voiture
sans savoir comment le moteur démarre. En programmation, c'est pareil. Chaque fonction est une boîte noire dont
on se contente de croire le nom.
C'est exactement pour ça que les développeurs découpent leur code en petits morceaux. Pas par plaisir de faire
plein de fichiers, mais pour que chaque morceau soit compréhensible individuellement. Si une fonction fait 200
lignes, personne ne peut la comprendre d'un coup d'oeil. Si elle en fait 5 et appelle 3 autres fonctions bien
nommées, n'importe qui peut la lire.
Exemple :
Compare deux façons d'écrire le même programme. La première aligne 50 lignes d'affilée qui récupèrent des données, font des calculs, formatent un résultat et l'envoient par email. La seconde confie chacune de ces quatre étapes à une fonction dédiée, et se contente de les enchaîner.
Voilà à quoi ressemble la seconde version.
function genererRapportMensuel() {
let ventes = recupererVentesDuMois()
let stats = calculerStatistiques(ventes)
let rapport = formaterRapport(stats)
envoyerParEmail(rapport, "equipe-direction@monentreprise.com")
}
Tu comprends le programme en 4 lignes. Chaque étape est une boîte noire dont tu sais ce qu'elle fait sans avoir
besoin de savoir comment elle le fait. Si tu veux creuser le détail du calcul des statistiques, tu vas regarder
la fonction calculerStatistiques. Sinon, tu passes.
C'est ça, la puissance du découpage. On lit le code au niveau de détail qui nous intéresse. Le directeur
lit les 4 lignes et comprend le processus. Le développeur ouvre calculerStatistiques pour corriger
un bug. Chacun lit ce dont il a besoin.
Repérer la structure
Quand tu regardes du code, ne te focalise pas sur chaque caractère. Repère la structure :
- Les blocs indentés après un
if: c'est une décision. "Si quelque chose est vrai, alors on fait ça." - Les blocs indentés après un
forouforEach: c'est une répétition. "Pour chaque élément, on fait ça." - Les lignes avec des parenthèses : ce sont des appels de fonction. "On délègue cette action à quelqu'un d'autre."
- Les
return: c'est la sortie. "Voilà le résultat."
Avec ces quatre repères, tu peux suivre la logique de n'importe quel morceau de code, même dans un langage que tu ne connais pas.
Un exemple complet
Mettons tout ça en pratique. Voici un programme réaliste. Essaie de le lire en suivant les noms et la structure, sans t'arrêter sur la syntaxe :
function traiterCommandesDuJour() {
let commandes = recupererCommandesEnAttente()
commandes.forEach(function(commande) {
if (commande.estPayee()) {
preparerExpedition(commande)
envoyerConfirmation(commande.client)
} else if (commande.estExpiree()) {
annulerCommande(commande)
notifierClient(commande.client, "Votre commande a expiré")
}
})
let stats = {
total: commandes.length,
expediees: compterExpediees(commandes),
annulees: compterAnnulees(commandes)
}
envoyerRapport(stats, "logistique@monentreprise.com")
}
En le lisant, tu reconstitues tout le processus. On récupère les commandes en attente, pour chacune, si elle est payée on la prépare
et on confirme au client, si elle a expiré on l'annule et on prévient le client, puis on envoie un rapport à
l'équipe logistique avec le résumé.
Tu ne sais pas comment preparerExpedition fonctionne en interne. Tu ne sais pas comment
envoyerConfirmation envoie l'email. Et ce n'est pas grave. L'abstraction te permet de comprendre
le "quoi" sans le "comment".
En pratique
La prochaine fois qu'un développeur te montre du code ou qu'on t'associe à une
revue de code, ne panique pas. Cherche les noms de fonctions, ils te disent ce que fait le programme.
Repère les if, ils te disent quelles décisions sont prises. Repère les boucles, elles te disent
ce qui est répété. Et si quelque chose n'est pas clair, demande simplement "cette fonction, qu'est-ce qu'elle
fait ?". Un
bon développeur saura t'expliquer, car si le code est bien découpé, chaque morceau a une responsabilité claire.
Si un développeur n'arrive pas à t'expliquer en une phrase ce que fait une de ses fonctions, c'est probablement que cette fonction fait trop de choses et qu'elle devrait être découpée.