Présentation

Pour commencer, une préface flatteuse de Ward Cunningham, considéré comme le créateur de concept de Wiki et l’un des pères d’une méthode de développement agile connue : l’Extreme Programming.

Concernant les deux auteurs : Andy Hunt et Dave Thomas, deux programmeurs et fondateurs de la maison d’édition The Pragmatic Bookshelf. Ce site propose des livres pour les développeurs au format papier ou électronique sans aucun DRM. Du contenu, même audio ou vidéo, pour apprendre ou s’améliorer sur un langage, une méthode, une techno Web, …

De bonnes choses pour attirer mon attention : on y parle de programmation sous fond de méthodes agiles, bonnes pratiques et de pragmatisme.

Avant de goûter

J’ouvre le livre, regarde rapidement la table des matières, saute la préface et feuillète rapidement. Première remarque : très très peu de lignes de code. Oui, nous sommes face à un livre sur la programmation que je qualifierais de non technique par opposition aux livres sur un langage, une technologie ou un logiciel.

Assis ou debout, matin ou soir, je continue ma lecture dans le métro parisien, avec ce livre rédigé en anglais, loin d’être un format “Poche”, avec comme photo de couverture un outil de menuisier — un rabot très certainement.

Un livre sur plusieurs aspects du travail quotidien d’un développeur à lire dans le métro avant de te rendre au boulot, démarrer ton ordi, ouvrir un terminal, puis Emacs et taper du code ?

Maso ? Pas tant que ça. Je tiens à dire qu’on ne lit pas ce livre par hasard. J’aime lire des bouquins sur des méthodes de gestion de projet informatique ou des méthodes de développement auxquelles je suis sensible. On ne se force pas à boire du thé vert en écoutant Ascension de John Coltrane si on n’apprécie pas l’eau chaude arômatisée et que l’on déteste le Free Jazz. Autrement dit, on lit des choses que l’on pense apprécier. Je ne suis donc pas si maso. De plus, je suis convaincu que de telles méthodes peuvent améliorer la qualité de mon travail et donc mon quotidien.

Et alors ?

Ce livre est une bonne occasion de prendre du recul sur soi, sur son travail et ses habitutes. La lecture de chacun des huit chapitres donne l’impression que les auteurs, dans leur travail de développeur, n’ont eu cesse de remettre en question chacune de leur tâche et de réfléchir aux moyens de les améliorer : rédaction de mails, organisation de réunions, échanges avec les utilisateurs, utilisation des bons outils, gestion des sources, débuggages, etc.

Conseils et Tips

Chaque section comporte un ou plusieurs tips. Dans la section concernant les risques de duplication de code, nous pouvons lire :

DRY: Don’t Repeat Yourself

ou encore :

Make it Easy to Reuse

Cela permet de donner un axe de lecture intéressant. Au-delà de la lecture en ligne droite, chapitre par chapitre jusqu’aux annexes, chaque section mentionne des tips décrits dans d’autres chapitres. Il peut alors être pertinent de picorer de-ci de-là des conseils, lire telle section, puis revenir ou au contraire se laisser porter au fil des tips.

Des évidences qui font du bien

Agréable à lire, les auteurs nous dévoilent leurs conseils, les expliquent, argumentent et assaisonnent leur raisonnement d’anectodes vécues. Pour quelqu’un de familier avec les méthodes dites agiles, on a parfois l’impression de lire des évidences. Néanmoins, la vision et les raisons de certains choix sont très bien expliqués. Cela permet entre autre de mieux en parler autour de soi et tenter de convaincre tel collègue ou chef de projet sur l’urgence d’une factorisation de code par exemple. Elle a certes un coût mais réduit la dette technique. Mieux vaut passer du temps à réparer rapidement cette fenêtre cassée avant que tout le monde néglige l’entretien de la maison.

Un métier d’artisan

Même pour quelqu’un qui ne programme que la moitié de son temps, pour quelqu’un qui n’est pas informaticien de formation, cet ouvrage me semble indispensable à lire. Il pose les bonnes bases : munis-toi de bons outils, apprends à utiliser efficacement un éditeur digne de ce nom. “Cette tâche est trop répétitive ?”, fais en sorte de rendre cela moins pénible. utilise donc un langage de script, une macro, … Rédige des fichiers textes : notes, fichiers de configuration, etc. Les fichiers textes, faciles à parser, permettent facilement d’automatiser le lecture pour en extraire une information pertinente ou de chercher un groupe de mots dans une série de répertoires. Un bon éditeur : vim, Emacs, éditeurs d’un autre temps ? Certainement pas. Au-delà de la programmation, on passe principalement du temps à rédiger : mails, rapport, notes, articles, etc. Fais en sorte d’être aussi efficace que possible.

Une métaphore que j’ai beaucoup appréciée dans le chapitre concernant les “outils de base” : les auteurs comparent la programmation au travail de menuiserie — note qu’on retrouve là la référence au rabot de la couverture, tu suis, c’est bien. La conception d’une ou plusieurs pièces en bois nécessitent de se munir des outils adéquats. Il est même envisageable de concevoir son propre outil pour rendre une tâche répétitive moins pénible. Le développeur doit faire de même.

Ton savoir : ton meilleur avenir

Une dernière chose et je te laisse découvrir le reste par toi-même : entretien et développe tes connaissances. Your Knowledge Portfolio nous montre le raisonnement suivant : expérience et connaissances sont les “actifs” du développeur. Ces actifs perdent de la valeur avec le temps : tes connaissances ne sont plus à jour, ton expérience est devenue obsolète. Pour y remédier, il faut investir de manière continue dans ce portefeuille de “savoir”, se diversifier, gérer les risques. Cela implique par exemple de faire de la veille , apprendre une nouvelle technologie, un nouveau langage, participer à des projets en-dehors du cadre professionnel, suivre des cours, lire des livres techniques et non techniques.

En espérant donner envie de lire ce très bon pragmatic livre … bonne lecture.