Les trucs à lire dans votre vie de dev

On m'a déjà demandé ce que je pouvais recommander comme lecture pour s'améliorer en tant que développeur. J'ai fini par écouter cette demande (particulièrement merci à toi Bich de m'avoir vraiment poussé sur ce sujet même si j'aurai mis du tout à le faire !) et me poser sur ce guide !

Avant-propos🔗

Je vous avoue que l'exercice est à mon sens assez difficile :

les livres techs ça coûte souvent cher (même très cher) ;
il n'y a pas une grosse offre côté occasion (même si vraiment il faut fouiller, ça vaut le coût !) ;
la masse des livres traitent d'une version d'un langage / outil / plateforme et sont vite dépassés ;
il faut se concentrer sur les livres qui partage des concepts / idées pour avoir quelque chose de plutôt intemporel ;
il y a souvent plusieurs éditions des livres, plus ou moins modernes, mais pour les livres à concept une ancienne édition fonctionne généralement très bien ;
pour moi le plus difficile pour les débutants : le gros de la littérature est en anglais, anglais un peu soutenu / formel, avec un vocabulaire pas toujours simple… ;

J'ai donc mis dû temps à écrire cet article parce que je voulais me laisser le temps de bien choisir le contenu qui allait y figurer ! Si à la base j'étais resté focus sur des livres papiers, je me suis finalement décidé à inclure d'autres ressources qui pour moi vont parfaitement dans cette catégorie.

L'open space m'a tuer — Alexandre des Isnards🔗

Je commence par un livre qui n'est pas du tout tech paradoxalement, mais que je trouve hyper important à lire, particulièrement en début de carrière, quand bien même je l'ai moi-même lu que l'année dernière.

L'open space m'a tuer est un livre qui m'a marqué car il évoque ce que c'est que de travailler dans un open space, de tout ce que ça implique, surtout de négatif. C'est quelque chose que je pense ait difficile à vraiment anticiper avant de l'avoir vécu. Je pense que ce livre m'aurait vraiment aidé.

Travailler en open space c'est subir un bruit constant, subir les échanges des autres personnes présentes, se gêner continuellement les uns les autres, ne pas avoir d'espace à soi (merci le sacro-saint flex office qui accompagne souvent l'open space), c'est voir / sentir les aller et venus de tout le monde continuellement, etc.

Ce livre est vraiment le symbole de tout ce qui se fait de pire dans l'open space. C'est une lecture très facile à mon sens, ça permet de bien se rendre compte de comment on vit l'open space mais aussi le travail de bureau avec tous ses codes, tous ses rituels, tous ses faux-semblants.

Quand bien même il y a des intérêts sociaux à l'open space, je pense qu'il y a surtout des inconvénients, particulièrement quand c'est mal vu de bosser avec un casque et de la musique pour s'isoler dans sa bulle…

Bref, un livre pas tech, mais qui représente un aspect important du travail de développeur, même si vous avez déjà de l'expérience : c'est un livre à lire !

12 factors app — Adam Wiggins🔗

Avant de passer à un autre livre, je vais passer sur la première ressource web. J'ai mis le lien vers la traduction française du site (traduction officielle, créé de manière collaborative sur le github 12factor), mais il existe aussi une version ebook (format epub, reprenant strictement le contenu de la version anglaise du site) qui n'est par contre elle disponible qu'en anglais. À vous de voir.

Le contenu est assez court (environ 25 pages au format livre), mais c'est un livre qu'on devrait tous avoir lu au moins une fois et même relire régulièrement !

On va y retrouver un tas de bonne pratique de conception d'une application en termes de construction, de déploiement, de configuration, monitoring, et tout ce qui va avec. On parle clairement de principes DevOps ici, mais sans forcer la référence à une technologie en particulier. Ici personne ne vous dira que vous devez faire une Kubernetes avec une image particulière, mais quelle méthodologie vous devriez utiliser peu importe la plateforme ou le langage.

J'ai lu ça en tout début de carrière, et clairement ça a été une brique fondamentale de ma manière de penser les applications ensuite.

Refactoring — Martin Fowler🔗

Ici on parle d'un livre d'un maître de l'informatique : Martin Fowler.

C'est un livre qui est très didactique, très orienté cas concret, avec beaucoup de méthodes. J'aime beaucoup ce livre, car il remet au centre du sujet le refactoring alors que c'est quelque chose qui est souvent relégué au second plan, une étape optionnelle qu'on ne fait que si on a le temps…

Refactoring va vous aider à vous projeter et à prendre du recul sur votre code. Il va vous aider en vous proposant des schémas reconnaissables pour améliorer votre code et vous assurer qu'il pourra évoluer, qu'il sera maintenable dans le temps, tout en vous fixant les bonnes limites, en vous posant les bonnes questions, en aidant à ne pas casser le projet en faisant ça.

Tous les exemples sont en Java, car c'est un des langages que Martin Fowler maitrise bien tout simplement, mais ne vous inquiétez pas de voir des éléments compliqués de Java moderne : il a été écrit en 1999, on est donc face à du très vieux Java (version 1.2), et plus ou moins tout est transposable à n'importe quel autre langage.

C'est un livre qui sera souvent trouvable neuf assez chers (50-100€), mais si vous cherchez un peu et/ou êtes patient, vous le trouverez assez souvent à une dizaine d'euros. À priori peu importe l'édition, le contenu ne change pas : j'ai une copie imprimé en 2012 mais indiqué comme l'édition de 1999. Tout le contenu est toujours d'actualité, au pire on peut faire encore mieux avec du Java plus moderne !

Note : j'ai parfois vu des livres qui semblent être des versions françaises de Refactoring, et mes recherches me laissent penser que le livre n'a pas été officiellement traduit. Donc je ne peux que vous orienter vers l'original en anglais, car c'est un anglais assez simple à lire et vous serez certain de la qualité du contenu.

Design Driven Development — Eric Evans🔗

C'est clairement un livre de référence.

C'est aussi un livre difficile à lire…

Je reste partagé par ce livre. Je suis globalement d'accord pour dire qu'on devrait appliquer à peu près tous les principes de DDD, mais je trouve que le livre est aussi assez difficile à lire et comprendre. Je pense que c'est un livre qui mérite d'être lu mais plutôt par morceau en revenant dessus régulièrement.

Je n'ai jamais réussi à finir ce livre à date, mais tout ce que j'en ai lu à changer ma manière de penser les projets. Et aussi fait réalisé qu'on loupe des étapes fondamentales…

Un exemple qui m'a vraiment marqué : l'ubiquitous language, avoir un langage (au sens : un vocabulaire) unique, clairement défini, qui repose la définition de chaque terme qui peut prêter à confusion pour quelqu'un d'extérieur au projet, avec si possible aucun ou presque synonyme, aucun "à peu près", etc. Tout ce qu'il faut pour que deux personnes, peu importe leur rôle dans l'équipe parle des mêmes entités métiers avec le même vocabulaire et se comprennent sans aucune ambiguïté. Ça parait évident et pourtant je n'ai jamais vu ça appliqué…

Je pense que c'est un livre dont il faut au moins lire les premiers chapitres qui sont fondamentaux et au pire basculer sur des ressources en ligne pour compléter.

The Agile Manifesto & Extreme Programming 🔗

Je regroupe les deux car pour moi c'est plus ou moins la même chose, car écrit plus ou moins par les mêmes personnes.

Note : pour les puristes qui passeraient pas ici, je sais que The Agile Manifesto et Extreme Programming c'est différent, MAIS pour moi on retrouve à peu près les mêmes idées, juste que Extreme Programming est pour moi plus précis, plus détaillé que The Agile Manifesto, un peu comme Scrum / Kanban.

Ces deux textes sont le socle de toutes les méthodes agiles : des principes et guides pour comprendre comment organiser un projet (au sens large) et comment l'équipe projet doit s'intégrer à l'organisation de l'entreprise et interagir avec les utilisateurs.

Ce ne sont pas des textes qui sont dirigistes mais plutôt qui vont vous aider à définir un cadre de travail saint, un cadre de travail où vous allez pouvoir délivrer de la valeur tout en vous adaptant aux changements (particulièrement aux changements dus à l'écart entre ce dont vos utilisateurs pensent avoir besoin et ce dont ils ont besoins réellement).

Conclusion🔗

Même si je ne devrais pas vraiment dire ça, mais si vous n'avez pas les moyens / ne vous sentez pas capable de lire un livre comme ça en anglais : n'hésitez pas à jeter un coup d'œil sur des sites comme Anna's Archive pour trouver une version epub et jeter un coup d'œil. Il sera toujours temps d'acheter le livre plus tard quand l'occasion se présentera !

J'espère vous avoir donné envie d'aller lire au moins une partie de ces livres / contenus avec mon article, en tout cas pour moi il s'agit de lecture qui m'ont vraiment été utile, et peut-être que ça pourrait l'être pour vous aussi !

Crédit photo : Générée via Mistral AI avec le prompt suivant :

A cozy, Ghibli-inspired illustration of a futuristic yet organic library. The scene features curved wooden bookshelves filled with floating books, including recognizable titles like "Domain-Driven Design" by Eric Evans, "Refactoring" by Martin Fowler, "The Agile Manifesto," and "Extreme Programming." A red panda, sitting cross-legged on a pile of books, holds a parchment with DevOps principles and code diagrams written on it. Around the red panda, holograms of keywords like "Ubiquitous Language" and "Clean Code" gently float in the air. Soft light filters through stained glass windows depicting autumn leaves, casting a warm golden glow over the scene. In the background, a Ghibli-inspired robot organizes books on the shelves. The atmosphere is serene, blending technology and nature, with a focus on timeless knowledge and the harmony between tradition and modernity.