#critique #livre « 97 Things Every Programmer Should Know »

J’avais terminé la lecture de cet ouvrage il y a quelques semaines, mais seulement publié sa critique la semaine dernière #viedeministre , voilà ce que j’en ai pensé :

« 97 Things Every Programmer Should Know » présente 97 conseils d’auteurs talentueux et célèbres (Kirk Pepperdine, Uncle Bob Martin…) aux programmeurs de tous horizons. 97 conseils pour 97 chapitres, 2 pages pour chacun, le livre présente 2 sommaires, le premier par ordre alphabétique des titres de chapitres et un second classement par catégories (Bugs and Fixes, Build, Deployment, Desgn, Coding, Error handling, Performance, Testing…)
On peut donc lire ce livre linéairement ou par thème, pratique selon son besoin au moment de la lecture. La lecture est facile, intéressante, passionnante et abordable pour un large panel de lecteurs. Par contre, bien que s’adressant à un public technique, il ne faut pas s’attendre à trouver beaucoup d’exemples de codes (voire quasiment aucun, à part « Code in the Language of the Domain » de Dan North ou « Missing Opportunities for Polymorphism » de Kirk Pepperdine), mais plus généralement des bonnes pratiques à suivre dans le quotidien du développement d’un projet informatique. Certains conseils se répètent, mais je dirais qu’ils sont présentés sous des angles différents, apportant une certaine ouverture sur l’appréciation d’un conseil. Bien sûr, les développeurs rodés aux bonnes pratiques penseront que les conseils prodigués enfoncent des portes ouvertes, mais applique-t-on toujours réellement ce qu’on peut apprendre en théorie ? La lecture de « 97 Things Every Programmer Should Know » sera peut être l’occasion de me faire mentir ! Parfois les auteurs auront des avis contradictoires, c’est aussi la richesse de cet ouvrage, une ouverture à la réflexion et le fait qu’il faille réfléchir avant d’appliquer bêtement la bonne parole. Mes chapitres préférés ? Ou plutôt quelques uns parmi d’autres :

• « The Boy Scout Rule » de Robert C. Martin (Uncle Bob), ou comment laisser un code meilleur après que vous l’avez trouvé ;
• « Check your code first before looking to blame others » de Allan Kelly, ou l’art de balayer devant sa porte avant celles des autres ;
• « Two heads are often better than one » de Adrian Wible, ou l’art du pair programming ;
• « Write test for people » de Gerard Mezsaros, ou comment la lecture de ce chapitre par mes prédécesseurs aurait pu m’aider sur un projet actuel pour comprendre mieux l’aspect métier.

Développeur depuis plusieurs années déjà, j’ai retrouvé dans ce livre beaucoup de choses que je pratique déjà mais j’ai également beaucoup appris à la lecture d’autres chapitres et au delà des conseils aux programmeurs on pourra aussi trouver application de certaines bonnes pratiques dans la vie quotidienne. Pour les débutants en programmation ce livre est à posséder absolument, pour les plus expérimentés je suis sûr qu’ils y trouveront leur compte ou tout du moins se rafraichiront la mémoire avec cette passionnante lecture. À noter également que le contenu de ce livre est sous licence Creative Commons accessible sur le site officiel, ça permet de se donner une idée avant l’achat physique du livre.

Vous trouverez ici ma critique du livre « 97 Things Every Programmer Should Know » , publiée la semaine dernière sur Developpez.com , mais également celle de @esiber .