Chapitre 5.4.9Lire du code

Comprendre un programme sans être développeur.

3 minutes de lecture

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 :

Lis les noms, ignore le reste
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.

Code découpé
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 for ou forEach : 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 :

Traitement des commandes du jour
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.

PrécédentLa programmation objet Tous les chapitres