The Pragmatic Programmer

1Vous êtes acteur, pas passager

Le livre s'ouvre sur un constat : beaucoup de développeurs subissent leur métier. Job ennuyeux, techno dépassée, équipe pénible. La réponse des auteurs tient en une question : « Pourquoi ne pouvez-vous pas changer ça ? » (Topic 1). Notre métier est en haut de la liste des carrières où l'on tient le volant : compétences demandées partout, télétravail possible, salaires corrects. « Essayez de réparer ça. Mais n'essayez pas éternellement » (Topic 1). Martin Fowler le dit avec un jeu de mots que le livre cite : you can change your organization or change your organization. Changez votre boîte, ou changez de boîte.

Cette posture a un revers : la responsabilité. Quand quelque chose rate, on arrive avec des options, pas des excuses (Topic 2, dont le titre dit tout : « le chat a mangé mon code source »). Et on entretient ses compétences comme un portefeuille financier (Topic 6) : investir régulièrement, diversifier, prendre quelques paris risqués, parce que « ce sont des actifs périssables ».

2Une seule fenêtre cassée suffit

Pourquoi un code propre se dégrade-t-il ? Le livre emprunte la réponse à la criminologie : un bâtiment intact reste intact, mais une seule fenêtre cassée non réparée le fait basculer dans l'abandon, parce qu'elle dit à tous ceux qui la voient : ici, personne ne s'en soucie. Même mécanisme dans le code : un module pourri toléré, et toute l'équipe glisse vers « le reste de ce code est nul de toute façon, je fais pareil » (Topic 3).

Le Tip 5 pose la règle : « Ne laissez pas de "fenêtres cassées" (mauvais designs, mauvaises décisions, code médiocre) sans réparation. Réparez chacune dès sa découverte. » Pas le temps ? Condamnez la fenêtre avec une planche : commentez le code fautif, affichez « non implémenté ». N'importe quelle action qui montre que quelqu'un tient la maison.

Cette idée a une jumelle : la grenouille ébouillantée (Topic 4), qui ne saute jamais de l'eau qui chauffe doucement. « La plupart des désastres logiciels commencent trop petits pour qu'on les remarque, et la plupart des dérapages de projet arrivent un jour à la fois. » La fenêtre cassée tue par découragement, la grenouille par inattention au changement graduel.

3Tout bon design se résume à « facile à changer »

C'est le grand ajout de la deuxième édition : une méta-règle qui unifie tout le reste, baptisée ETC, Easier to Change, plus facile à changer. Pourquoi le découplage est-il bon ? Parce que ce qui est isolé est plus facile à changer. Pourquoi la responsabilité unique ? Parce qu'un changement d'exigence ne touche qu'un seul module. « Une chose est bien conçue si elle s'adapte aux gens qui l'utilisent. Pour du code, cela veut dire qu'il doit s'adapter en changeant » (Topic 8).

ETC est une valeur, pas une règle : à chaque sauvegarde, est-ce que je viens de rendre l'ensemble plus facile ou plus difficile à changer ? Concrètement, devant deux façons d'écrire la même chose, on choisit celle qui encaissera la prochaine demande sans qu'on rouvre le code :

// ✗ difficile à changer : ajouter un canal = rouvrir cette fonction
function notifier(canal, msg) {
  if (canal === 'email') envoyerEmail(msg)
  else if (canal === 'sms') envoyerSms(msg)
}

// ✓ facile à changer : ajouter un canal = une ligne, AILLEURS
const canaux = { email: envoyerEmail, sms: envoyerSms }
function notifier(canal, msg) { canaux[canal](msg) }
canaux.push = envoyerNotifPush   // le nouveau canal, sans toucher à notifier()

Les deux marchent aujourd'hui. Mais le second a déplacé le point de changement hors de la logique : c'est ça, ETC. Son corollaire (Topic 11) : aucune décision n'est définitive. Voyez les choix techniques comme « écrits dans le sable de la plage », pas gravés dans la pierre. En vingt ans, l'architecture standard est passée du gros serveur central aux clusters, au cloud, aux microservices, au serverless : parier sur la stabilité d'un choix technique est le seul pari perdu d'avance.

4DRY ne parle pas de copier-coller

DRY est probablement le principe le plus cité du métier, et les auteurs avouent qu'il est massivement mal compris depuis vingt ans. La définition exacte : « chaque morceau de connaissance doit avoir une représentation unique, non ambiguë et qui fait autorité dans le système » (Topic 9). Le mot important est connaissance, pas code.

Deux fonctions au code identique ne violent pas forcément DRY :

• validate_age et validate_quantity vérifient toutes les deux qu'un nombre est positif. Même code, mais deux règles métier distinctes, qui évolueront séparément. Les fusionner serait l'erreur.
• À l'inverse, la même règle métier recopiée dans la base, le back et le front viole DRY, même si les trois bouts de code ne se ressemblent pas du tout.

L'anecdote qui fait mal : lors d'un audit pour l'an 2000, un État américain a découvert plus de 10 000 programmes contenant chacun sa propre version de la validation du numéro de sécurité sociale.

5Balles traçantes : visez avec du vrai code

Comment démarrer un système dont personne ne connaît encore la cible exacte ? L'approche classique construit couche par couche (toute la base, puis la logique, puis l'interface) et prie pour que tout s'emboîte à la fin. Le livre propose l'inverse : les balles traçantes. Dans l'obscurité, les tireurs chargent des munitions phosphorescentes parmi les vraies : elles dessinent le trajet réel, en conditions réelles, et permettent d'ajuster le tir.

En code : construire d'abord une tranche ultra-fine qui traverse toutes les couches de bout en bout. Un écran, une requête, un résultat affiché. Pas un brouillon : du code de production, juste maigre. « Le code traçant n'est pas jetable : vous l'écrivez pour le garder » (Topic 12). C'est toute la différence avec le prototype (Topic 13), jetable par définition : « le prototypage génère du code jetable. Le code traçant est maigre mais complet. »

Ce que la tranche fine change :

• les utilisateurs voient quelque chose tourner dès les premiers jours ;
• l'équipe a un squelette à remplir au lieu d'un plan à imaginer ;
• la progression devient honnête : fini le module « fini à 95 % » depuis trois semaines.

6L'héritage est un impôt

Le Topic 31 s'ouvre sur une citation de Joe Armstrong : « vous vouliez une banane, mais vous avez eu un gorille qui tenait la banane, et la jungle entière ». C'est l'héritage en une phrase : on hérite pour un comportement, on récupère tout l'état, toutes les dépendances, et les dépendances des dépendances. L'héritage est du couplage : si Vehicle renomme une méthode interne, le code qui utilise Car casse en silence.

La position du livre est tranchée : arrêtez. Pas parce que c'est mal en soi, mais parce que les alternatives font mieux à chaque fois :

• les interfaces : du polymorphisme sans hiérarchie (Car implements Drivable) ;
• la délégation : avoir-un bat être-un ; l'objet contient un service et lui confie le travail ;
• les mixins : partager un paquet de fonctions sans lien de parenté.

// ✗ héritage : pour UNE méthode (log), on traîne tout ServiceComplet
class Facture extends ServiceComplet {}   // le gorille et la jungle

// ✓ délégation : Facture A-UN logger, et lui confie juste ce qu'il faut
class Facture {
  constructor(logger) { this.logger = logger }  // juste la banane
  payer() { this.logger.info('payée') }
}

Même combat contre le couplage ordinaire (Topic 28) : la chaîne d'appels customer.orders.find(id).getTotals().grandTotal traverse cinq niveaux de structure interne ; chacun peut casser votre ligne. La règle : dites, ne demandez pas ; déléguez à l'objet qui possède les données. Les auteurs rétrogradent même leur propre Loi de Déméter (la règle anti-chaînes d'appels qu'ils avaient eux-mêmes popularisée), vedette de la première édition (« le charme de cette rose-là a fané »), au profit d'une version plus simple : pas plus d'un point par accès.

7Le vrai bénéfice des tests, c'est d'y penser

Voilà le passage le plus inattendu du livre. Les auteurs, qui ont contribué à populariser les tests unitaires, écrivent : « nous pensons que les bénéfices majeurs des tests arrivent quand vous réfléchissez aux tests et que vous les écrivez, pas quand vous les exécutez » (Topic 41). Un test est le premier utilisateur de votre code, et il dénonce les défauts de conception avant tout le monde :

// la fonction crée elle-même sa dépendance : impossible à tester sans vraie horloge
function estExpire(token) { return token.fin < Date.now() }
// pour tester, il faudrait attendre vraiment, ou bidouiller l'horloge système…

// écrire le test FORCE à injecter le temps → meilleure conception, gratuite
function estExpire(token, maintenant) { return token.fin < maintenant }
estExpire(token, 1000)   // testable en une ligne, le test a révélé le défaut

On n'a jamais lancé le test, et il a déjà payé : c'est en cherchant à appeler la fonction qu'on a vu que la dépendance cachée (l'horloge) devait s'injecter. C'est ça, « réfléchir aux tests » qui rapporte plus que les exécuter.

Le livre documente aussi les dérives. En 2006, Ron Jeffries, un des signataires du manifeste agile, tente de résoudre un sudoku en TDD strict : cinq articles de blog à raffiner sa représentation de données, tests au vert à chaque étape, puis abandon sans solveur. Peter Norvig part de l'algorithme et le règle en quelques lignes. Morale du livre : « une personne brillante peut se perdre dans les détails, confortée par la lueur des tests qui passent ».

Et puis il y a la confession de Dave : il a arrêté d'écrire des tests pendant deux mois, pour voir. Effet mesuré : « pas grand-chose ». Andy désapprouvait la publication de cet encadré. La conclusion de Dave est tout sauf un permis de paresse : « Devriez-vous écrire des tests ? Oui. Mais après trente ans de pratique, autorisez-vous à expérimenter un peu. »

8« Agile » est un adjectif, pas un nom

Après la Seconde Guerre mondiale, des habitants d'îles de Mélanésie ont reconstruit des pistes et des tours de contrôle en noix de coco et feuilles de palme, pour faire revenir les avions pleins de marchandises qui atterrissaient pendant le conflit. Le livre appelle ça par son nom, le culte du cargo, et le retourne contre nous (Topic 50) : copier les rituels de Spotify ou Netflix sans leur contexte, c'est construire une tour de contrôle en noix de coco. Tip 87 : « faites ce qui marche, pas ce qui est à la mode ».

La vraie agilité n'est pas un processus qui s'achète, c'est une boucle (Topic 48) :

1. regarder où on est ;
2. faire le plus petit pas significatif vers où on veut aller ;
3. évaluer ce qui a changé, et corriger ce qu'on a cassé.

La boucle s'applique à tous les étages : renommer une variable, choisir une architecture, orienter un projet. Stand-ups hebdomadaires, « itérations » de huit semaines et un outil de planification comme seul artefact : ce n'est pas de l'agilité, c'est le costume. « Agile n'est pas un nom ; agile, c'est une façon de faire les choses » (Tip 83).