Quelques livres essentiels pour un informaticien

C’est la mode sur internet de faire des listes avec “les 10 meilleurs blogs d’info” ou “6 raisons de programmer en Python”, etc. Du coup, je m’y mets aussi avec une liste toute personnelle de livres “fondateurs”. Il s’agit des quelques livres que je considère comme les plus influents sur mon mode de pensée. Ceux qui ont modifié ma perception du métier. Bien sûr, ça s’applique à ma façon de penser, et ça n’a rien de général, mais je pensais que ça valait le coup de faire cette liste, ne serait-ce que pour mettre en avant ces livres qui le méritent bien.

La liste est bien pour un informaticien au sens large, et pas pour de la programmation. En fait, les livres techniques marquent rarement l’esprit. Ils peuvent bien sûr être de très grande qualité, mais leur utilité n’est qu’en réponse à des questions qu’on se pose. Les grands livres sont ceux qui font qu’on se pose des questions auxquelles nous n’avions jamais pensé avant. Et ce sont souvent des livres sur la méthodologie, l’architecture, les bonnes pratiques.

Clean Code (Robert Martin)

A tout seigneur, tout honneur. Si vous n’aimez pas lire, et que vous êtes d’accord pour faire l’effort à condition d’apprendre énormément, mais en un seul bouquin, c’est celui-ci qu’il faut lire.

Clean Code, comme son nom l’indique, vous apprend tout simplement à coder proprement.

Je suis souvent surpris par les cours de POO qui mettent l’accent sur l’héritage alors qu’on ne s’en sert finalement que très peu, et laissent de côté les interfaces, alors que c’est la base de n’importe quel code correctement architecturé. Ce livre nous apprend comment bien utiliser les interfaces pour assouplir le code, comment nommer proprement les variables, comment gérer correctement les erreurs, etc.

En fait, n’importe quelle personne qui programme devrait avoir lu “Clean Code” avant de livrer le moindre bout de ligne en production.

Le But (Eliyahu Goldratt)

Il semble que ce soit une marque de fabrique des grands livres : ils expliquent des évidences qui ne le sont pas avant qu’on les découvre.

Une des choses qui m’a le plus frappé est la démonstration qu’une usine peut aller plus vite si on laisse à un moment donné des gens ne pas travailler. Ca parait complètement contre-intuitif, voire absurde. Il est possible que quelqu’un qui ne fait rien empêche du coup la production d’augmenter, mais comment le fait qu’il travaille pourrait avoir pour effet de baisser la production totale ? La solution réside dans le fait que notre modèle de la production est trop simple. On pense que ce qui est réalisé sort, mais on ne prend pas en compte les interactions entre les processus, et les goulets d’étranglements.

Le cas d’école est celui d’une machine-outil inutilisée. La patron passe dans les ateliers, met un savon à un ouvrir qui a les bras croisés et lui demande de faire quelque chose. L’ouvrier décide alors de constituer un petit stock de soupapes, pour la prochaine commande. Manque de chance, alors qu’il vient de faire ses réglages d’outils, une autre section de l’atelier n’a plus de stock de cames, et lui en demande. Le voila donc à perdre du temps pour régler la machine, retardant ainsi les autres, et au final potentiellement toute la chaine de production du moteur. Au final, le patron aurait mieux fait de laisser l’ouvrier se reposer pour le prochain rush, ou encore mieux aurait du réfléchir à l’endroit où l’ouvrier aurait pu aider à accélérer un autre processus.

L’auteur explique ça cent fois mieux que moi, et surtout propose des solutions simples et éprouvées (par Toyota en particulier, dans son approche Lean de flux tiré pour réduire les stocks et les gaspillages). En plus de cela, le livre est écrit comme un roman initiatique, se lit très facilement, et explique clairement les principes de Drum Buffer Rope.

Bref, si vous voulez comprendre comment travailler plus peut vous faire perdre de l’argent si vous ne travaillez pas intelligemment, c’est l’ouvrage de référence.

Design Patterns (Gamma, Helm, Johnson & Vlissides)

Qui n’a pas entendu parler du célèbre “Gang of four” ? Ces quatre-là sont à l’origine de la formalisation de la plupart des patterns de programmation objet.

Là encore, c’est une marque des grandes avancées que de fournir des résultats qui paraissent des évidences quand on les lit. La plupart des patterns sont logiques, irréfutables, et on se prend même à se dire qu’on aurait pu les inventer nous-mêmes si besoin. C’est d’ailleurs le propre des patterns de ne pas être une invention à proprement parler, mais une bonne pratique issue de nombreuses personnes sans lien, et qui s’impose comme la bonne façon de faire.

Mais mettre tout ceci dans un seul livre, expliquer leur substantifique moëlle, nommer les choses (une des grandes difficultés en informatique), c’est un énorme travail, et qui sert désormais à des millions d’informaticiens dans le monde.

Entreprise Integration Patterns (Hohpe & Woolf)

Ce livre est la bible des urbanistes et architectes logiciels. Il pose les fondements de l’architecture de médiation nécessaire à garder des systèmes d’information souples.

Surtout, ce livre est à l’origine d’un véritable standard de fait, car les EIP présentés sont devenues la référence des atomes de composition des routes de médiation et d’orchestration dans les middleware orientés messages.

Si vous êtes amenés à faire interopérer des systèmes informatiques, et que vous n’avez le temps de lire qu’un seul livre, c’est celui-ci qu’il faut lire. Pas nécessairement en entier, mais comprendre tous les patterns est un apport énorme. Les explications sont extrêmement détaillées sur chaque, mais une première lecture peut tout-à-fait être réalisée en se bornant à comprendre le principe de chaque pattern. Le livre sera ensuite une ressource précieuse lors de l’application d’un pattern en particulier pour connaitre ses caractéristiques, mieux comprendre comment le mettre en œuvre, les pièges associés dans lesquels vous tomberez forcément si vous ne vous documentez pas, etc.

Writing SOLID code (Maguire)

Une fois que vous connaitrez les patterns de programmation orientée objet, vous vous rendrez certainement compte qu’il émerge une sorte de “meta-pattern” de programmation consistant à utiliser les interfaces comme des contrats permettant de développer des blocs plus autonomes, sous forme de composants.

Cette approche est formalisée dans cinq grands principes qui sont le principe de responsabilité unique (S pour Single Responsibility), le principe Ouvert / Fermé (O pour Open/Closed), le principe de substitution de Liskov (L), le principe de ségrégation d’interface (I) et le principe d’inversion de dépendance (D).

Ce livre pose ces principes et les détaille en profondeur, en expliquant comment ils sont utilisés ensemble pour parvenir à une architecture souple.

SOLID a souvent été appelée “POO made right”. Personnellement, je suis assez d’accord avec le fait qu’on ne devrait pas faire de programmation orientée objet sans connaitre les cinq principes SOLID.

Hard Code (Brechner)

Full disclosure, tout d’abord : je tiens à préciser que je suis le traducteur de cette œuvre en français. Mais ce n’est pas parce que je le traduis que je veux le mettre en avant. Au contraire, justement : je fais l’effort de le traduire parce que je considère que le bouquin le vaut.

Pour l’anecdote, l’éditeur français n’était pas intéressé par une traduction, et j’ai racheté les droits avec mes propres sous pour pouvoir réaliser cette traduction, car ce livre me parait absolument essentiel. Payer pour bosser, c’est un concept nouveau… Comme dirait ma femme : “t’as intérêt à en vendre !”  On verra si c’est le cas, mais même si je n’en vends que quelques-uns à mes proches collègues, je serai satisfait. C’est d’ailleurs une d’entre elles qui a été le déclencheur de la traduction. Considérant que le sujet était essentiel, j’avais fait un petit retour sur quelques heures en interne, en disant à mes collègues à la fin de la présentation que ce serait bien qu’ils lisent le tout. La collègue en question m’a dit qu’elle le ferait si c’était en français. Je l’ai prise au mot…

Mais venons-en au plus important : le livre, et son contenu à la fois riche et déroutant, déjanté, parfois à la limite de la politesse, également controversé, polémique à dessein, parfois extrêmement cérébral mais toujours plein de bon sens.

Eric Brechner a regroupé dans ce livre une centaine de ses plus grands succès dans les articles de blogs qu’il publie en interne à Microsoft depuis une bonne dizaine d’années, sous le pseudo de I.M. Wright (“Monsieur J’ai Raison”). Ses articles sont dérangeants, polémiques. Il n’hésite pas à appeler un chat un chat, et s’il considère que Microsoft ne fait pas bien quelque chose, il le dit tel quel : “nous sommes nuls” (et j’édulcore sévèrement le vocabulaire, bien plus… disons charpenté).

Chaque article surprend le lecteur dès le début, l’interpelle au minimum, voire suscite une réaction épidermique. On a parfois l’impression de se faire alpaguer, puis secouer par le col. Lors de la première lecture de ce livre (j’en suis à la troisième, et j’en apprends encore), combien de fois me suis-je dit “là, il raconte vraiment n’importe quoi”, pour, quelques pages plus tard à peine, me dire que c’était un génie, qu’au contraire, sa conclusion était frappée au coin du bon sens. Eric Brechner nous fait parfois nous sentir idiots : vexés d’être tombés dans le piège qu’il décrit, et encore plus lorsque la solution nous apparait, simple, logique, indiscutable.

J’ai eu l’honneur de rencontrer Eric Brechner en vrai, lors du MVP Summit de Microsoft à Seattle. Il m’a consacré une heure de son emploi du temps de ministre, et rien que dans cette heure, j’ai appris plus qu’en plusieurs formations sur la gestion des équipes informatiques.

Ingénierie et Intégration des Systèmes (Meinadier)

Celui-ci, c’est le prototype du bouquin qu’il vaut mieux ne pas lire avant d’avoir une bonne connaissance du sujet de l’ingénierie informatique. Ce n’est pas un livre qui a été écrit pour introduire, expliquer ou détailler. C’est un bouquin dont le but est de formaliser, de conceptualiser. Bref, compréhensible seulement après au moins cinq ans d’expérience, mais qui vous permet de structurer fortement vos connaissances, de les charpenter et de combler tous les trous dans votre expérience terrain.

Que ce soit sur le maintien en condition opérationnel, la façon théoriquement propre de concevoir des cahier des charges, le bon vocabulaire pour gérer l’intégration de grands systèmes, ce (vieux) livre est une somme. Clairement, il est plus destiné à des architectes, directeurs techniques chez des éditeurs ou directeurs de systèmes informatiques qu’à des programmeurs. Mais il reste une excellente lecture pour ces derniers, une fois experts.

Un grand merci à ce client – d’origine Frioulane comme moi – qui m’a pointé vers cette excellente source.

Domain Driven Design (Evans)

Un autre bouquin très connu, ou en tout cas sur un sujet qui a fait beaucoup de bruit. Ils sont rares ces livres ou ces auteurs qui inventent un pan complet de l’industrie informatique et dont le concept phare devient une façon de faire reconnue comme innovante et largement diffusée. C’est le cas pour ce livre d’Evans qui a posé les bases du Domain-Driven Design, et influé sur de nombreux architectes.

Les liens avec l’agilité ainsi qu’avec les approches CQRS sont aujourd’hui évidents, mais à l’époque de son écriture, ce bouquin avançait sur des concepts complètement nouveaux, et qui allaient à l’encontre des approches traditionnelles de conception et de modélisation.

Le simple fait que la préface soit de Martin Fowler suffisait presque à dire que c’était un bon bouquin, mais à le lire, on sait que c’est le genre de livre qu’on ne revendra pas, et qu’on relira certainement de temps à autre pour continuer à glaner des idées supplémentaires. Un peu comme une bonne BD qu’on relit souvent car on y trouve à chaque fois quelque chose de nouveau.

Effective C# (Wagner)

et

Peut-être pas des livres aussi importants que les précédents, mais quand je faisais la liste dans ma tête des livres qui m’ont réellement marqués, ces deux-ci arrivent juste derrière. Il se peut que ce soit du à un contexte particulier de lecture à l’époque, mais le contenu, bien qu’inégal, n’en est pas moins de très bonne qualité.

Le gros avantage de ce livre est qu’il ne s’adresse qu’à des personnes qui connaissent déjà bien .NET, et ne veulent que découvrir des “gotchas” (des moments “eurêka”, pourrait-on traduire). Du coup, en quelques pages, on apprend beaucoup de choses, alors que dans les bouquins techniques traditionnels, qui reprennent toujours la base, ne serait-ce que rapidement, on se retrouve souvent à aller directement vers les derniers chapitres pour apprendre plus.

Pour ma part, je considère que ce sont ces lectures qui m’ont fait passé du stade de simple programmeur à celui d’informaticien professionnel.

Et en dernier… le vôtre !

En numéro 10, j’aurais pu mettre un des miens, pas pour le mettre en avant en tant que livre, mais pour dire que ce qui vous marquera et vous développera le plus en tant qu’informaticien (et, oserais-je le dire, en tant que personne), c’est bien de vous lancer et d’écrire le vôtre :

• Rien de mieux que de passer des jours et des heures à chercher comment expliquer un concept de la manière la plus simple possible pour le maitriser complètement.
• Rien de mieux que de se mettre à écrire pour se rendre compte que, finalement, ce sujet dont on se croyait expert, eh bien il nous reste encore pas mal de recherche et de lecture à réaliser pour vraiment le devenir.
• Rien de mieux qu’avoir pesté contre une critique d’une personne qui se permet de faire des remarques sur un sujet qui n’était pas celui poursuivi pour apprendre à soi-même être beaucoup plus attentif et précis dans ses propres remarques.

Bonne lecture, et je suis intéressé par toute liste similaire si vous en faites une.