Note : 9 ; Think! About your work; Book of the year (ex-æquo) 2002
Pensez! Mais pensez à la façon dont vous travaillez! Tel pourrait être le credo des auteurs de ce livre. Cet ouvrage ne traite pas de processus de développement logiciel à proprement parler, il expose plutôt une façon de se comporter et d’appréhender le développement logiciel au quotidien.
L’activité de développement logiciel est-elle un travail systématique décrit par des règles rigides? A cela les auteurs répondent: non! Ils abordent d’ailleurs le travail du développeur d’avantage comme l’activité d’un artisan que comme un travail d’ingénierie. Bien loin d’être un parallèle défavorable, il faut y voir une valorisation de notre travail, quand pour chaque problème il faut chercher une solution réfléchie, pragmatique et adaptée. Certains l’auront déjà compris, c’est d’agilité dont nous parlons ici ! Publié en 2000, il ne s’agit pas là d’une adhésion tardive à un effet de mode, mais au contraire le fruit de réflexions de « véritables croyants ». D’ailleurs Hunt et Thomas sont parmi les signataires originaux de l’agile alliance.
Le livre se découpe en 8 chapitres qui regroupent au total 70 « tips » (il y a un aide mémoire avec le livre).
Chap 1 : Pragmatic philosophy. On nous enseigne ici les lignes directrices de l’agilité : le « juste assez », l’entropie du logiciel, …
Chap. 2 : Pragmatic approach. Ce chapitre traite des tactiques de réalisation : la « balle traçante » ou le langage du domaine, par exemple.
Chap. 3 : Basic tools, traite de l’environnement, outils d’édition, de build ou de génération de code. Bref, c’est pour l’usine logicielle !
Chap. 4 : Pragmatic paranoia (là, c’est pour moi) nous enseigne l’anticipation des comportements erronés.
Chap. 5 :Bend or break, traite de conception (donc de patterns) et de sa bonne mise en œuvre.
Chap. 6 : While you are coding évoque tout ce qui gravite autour de l’implémentation : les tests, le refactoring, etc…
Chap. 7 : Before the project, car il ne faut pas confondre vitesse et précipitation ! On parle ici de spécifications, mais aussi des travers qui peuvent en découler.
Chap. 8 : Pragmatic projects, évoque la dimension stratégique du projet : la gestion des tests, le cycle itératif, etc…
Ne vous y trompez pas: ce livre ne vous expose pas comment programmer. Il existe pour cela d’autres ouvrages dédiés aux langages de programmation, par exemple. Une partie (importante) du texte est toutefois dédié à des aspects de conception générale: programmation défensive, méta programmation, architecture MVC.
Mais pour moi l’intérêt principal du livre n’est pas là. Son intérêt principal est de nous montrer que la responsabilité d’un ingénieur de développement ne se limite pas à écrire du code. Notre responsabilité est de livrer un développement dont nous pouvons être fiers, de qualité et répondant aux réels besoins utilisateur. Un travail que nous pourrions même signer: fruit d’une élaboration sérieuse, robuste, bien écrit et convenablement documenté. Un travail professionnel, réalisé par un vrai professionnel, un “pragmatic programmer”.
Ai-je oublié de vous dire que je recommande fort chaudement cet excellent ouvrage ? Mais notez au passage le vocabulaire plutôt riche employé dans le texte, qui peut en rendre la lecture légèrement difficile.
Référence complète : The Pragmatic Programmer: From journeyman to master – Andrew Hunt & David Thomas – Addison Wesley 2000 – ISBN: 0-201-61622-X
Software Freethinker 
