Livres (Avis)
Cette page regroupe des avis totalement subjectifs sur différents livres que j’ai pu lire en rapport avec l’informatique, l’image, etc.
Fundamentals of Software Architecture
Ce livre est très didactique. Il commence par définir une dizaine de termes liés à l’architecture logicielle (cohésion, couplage, etc.), il explique ensuite comment les mettre en relation vis-à-vis de problèmes précis, puis les utilise pour faire un état des lieux et commenter les styles d’architectures de logiciels connues. La structure est simple, mais efficace.
Je suis toujours dubitatif face à ce type d’ouvrages qui tombent souvent dans de l’abstraction pure. Ce n’est pas le cas de Fundamentals of Software Architecture qui navigue avec justesse entre concept abstraits et problèmes concret. Les quelques exemples et anecdotes apportent juste ce qu’il faut de consistance aux savoirs qui sont exposés.
Ce livre ne vous apprendra pas à organiser votre code ou compiler vos paquets, mais vous donnera les clefs pour comprendre précisément les implications de vos choix quand vous allez commencer à séparer et organiser les choses. La question est toujours celle d’évaluer correctement les compromis qu’on fait.
Comme je le disais, ce qui m’a étonné c’est l’organisation du livre et la clarté de son propos. C’est très peu verbeux, il va à l’essentiel sans se perdre dans les détails. Les chapitres s’enchaînent de façon très fluide et logique. J’ai eu du mal à décrocher du chapitre sur les styles d’architectures ou l’auteur fait le pari de « noter » chaque aspect d’une architecture donnée pour s’en servir comme prétexte aux commentaires. C’est sûrement la partie la plus didactique du livre. Les types de logiciels analysés sont assez variés et on en viendrait presque à le faire sur ses propres codes. Les schémas sont nombreux et leur qualité confirme la maitrise des auteurs à communiquer le fond de leur pensée.
Je recommande cette lecture à tous ceux qui ont un eut à structurer des programmes qui grossissaient. Un chapitre parle d’ailleurs des risques à utiliser des architectures plus complexe que nécessaire en analysant le « saut » qu’il y a entre une architecture monolithique et une architecture distribuées.
Le livre se termine par un dernier chapitre, plus court que les autres (mais tout aussi nécessaire), sur les compétences humaines qu’un architecte doit mettre en œuvre pour piloter correctement les déférents intervenants. Le difficile équilibre entre être directif et laxiste y est commenté. Ça sent le vécu.
Designing Data-Intensive Applications
Sous-titré : « The Big Ideas Behind Reliable, Scalable, and Maintainable Systems », par Martin Kleppmann.
Excellent livre, parfois considéré comme la référence sur ce qui a trait aux bases de données. Et pour cause : Il va très loin dans son sujet.
Il commence par décrire le fonctionnement de la plupart des types de bases de données en suivant l’historique de leur développement et les spécificités de chacune. Vient les différents types de transactions (synchrone, asynchrone, etc.), les problèmes qu’elles posent, comment les contourner et les autres problèmes que posent ces contournements… Les derniers chapitres sont spécifiques aux architectures dites « distribuées » en présentant également les problèmes, les contournements et les problèmes des contournements…
Le gros du livre a donc cette forme, avec souvent exemple de situation réelle (le livre est très sourcé). Il n’y a donc jamais de solutions, mais des études de cas. C’est passionnant.
Comme je le disais, le nombre de situations présentées est important et la profondeur des explications peut rendre la forme un peu verbeuse. Si comme moi vous ne souhaitez pas pousser cet apprentissage, la fin du livre peut s’avérer fastidieuse. Pour autant, si votre travail consiste à gérer des infrastructures distribuées, ce type de savoirs me semblent être un prérequis.
Game Engine Black Book: Wolfenstein 3D
Premier livre de Fabien Sanglard.
Pour ceux que ne connaissent pas, l’auteur a un blog dans lequel il décortique et commente des codes sources de jeux plus ou moins récents.
Le livre est dans cette veine : Il décortique les particularités du matériel de l’époque et comment l’équipe d’ID a contourné ces limitations pour faire leur fameux jeu. Il raconte également l’histoire du développement du jeu. L’endroit où l’équipe développait, comment ils étaient organisés, etc.
Différents effets du jeu (le rasterizer, la transition en cas de mort du joueur, etc) sont creusé en détails, du petit morceau d’assembleur à une explication plus globale avec des schémas.
Il s’agit avant tout d’un livre de détente pour qui est à l’aise avec l’exploitation d’architectures limités et spécifiques. Ayant codé un peu dans l’émulateur mupen64plus (en particulier, la partie concernant la puce graphique), j’étais aux anges.
Scrum
Sous-titré : « Le guide pratique de la méthode agile la plus populaire », de Claude Aubry.
Le livre est bien écrit, plein de schémas et dessins humoristiques qui changent un peu des lectures habituelles.
Malgré cela, sa lecture m’a été difficile. L’auteur pousse l’application scrupuleuse d’une méthode, en justifiant d’appliquer des concepts que je trouve artificiellement rationalisé. On a l’impression d’un livre destiné au non-codeurs qui veulent pouvoir justifier une autorité auprès de leurs équipes.
Je ne remets bien évidement pas en question la méthode dite « Scrum », mais plus la façon dont l’auteur pousse le lecteur à l’utiliser : « Si ça ne marche pas, c’est pas la faute à Scrum, c’est que vous ne l’utilisez pas bien ». Ce mantra est répété plusieurs fois dans le livre, quasiment littéralement. L’apport majeur du « mythe du mois-homme » est que justement, aucune méthode de développement ne peut se soustraire du contexte (interne et externe) dans laquelle elle évolue, et c’est parce que ces observations se sont révélé juste que des courant tels que « la programmation extrême » (dont Scrum fait partie) sont apparu, avec pour ambition toujours réajuster l’avancement d’un projet à son contexte. Ici, l’auteur rappel de nombreuses fois que le problème est rarement la méthode, et pousse à l’utiliser tel que décrite.
Ce manque d’humilité et le fait de balayer, tout au long du livre, le contexte pour pousser ces concepts abstraits ne me semble pas pertinent, voire dangereux pour le projet et ceux qui en dépendent.
Ce livre me rappelle plutôt le ton de certains managers/responsables qui peuvent se retrouver perdus dans le flux, parfois tendu, d’un projet, et qui n’ont comme soupape mental, que le fait de faire des abstractions sur les problèmes réels que rencontre leur équipes. Si vous êtes manager, sachez que ça se voit et vous n’obtiendrez comme approbation que des hochements de tête silencieux pour ceux qui ne veulent pas se mouiller, ou des soufflements du nez pour les plus communicatifs. Ne soyez pas ce manager que tout le monde méprise, car il ne veut pas voir qu’il est incompétent en pensant que personne ne le remarquera. Il n’y a pas de honte à ne pas savoir coder, mais cacher son incapacité à gérer des situations en s’appuyant sur une prétendue « rigueur » d’application de méthodes est la pire des choses à faire.
J’ai bien conscience que la méthode « Scrum » ne s’applique pas qu’à des projets de développement, et peut-être que ce livre est plus pertinent pour d’autres domaines, mais en l’état, je pense qu’il est trop abstrait. Et dans le cas du dev, faire abstraction de comment les choses sont faites est souvent synonyme d’aller dans le mur dès que les complications apparaissent.
Ce livre est à prendre pour ce qu’il est, un livre qui propose une approche qu’il prétend concrète pour régler des problèmes qui ne sont jamais énoncés, et par extension, ne peuvent être qu’abstraits. Au lecteur d’adapter ça à sa situation, car le livre ne vous y aidera pas. J’avais déjà remarqué cette tendance dans certains livres de gestion de projets, ça m’a toujours paru bizarre de décorréler à ce point les problèmes, spécifique au domaine d’application, de la méthode d’organisation générale, comme si le fait que l’organisation soit globale impliquerait qu’il n’est pas nécessaire de prendre en compte le domaine d’application. Je dois rater un truc…
Préférant travailler dans le vrai monde, et au vu de la quantité de livre proposant de régler des problèmes concrets précis, je vous conseille plutôt de trouver des livres traitant spécifiquement du sujet que vous souhaitez aborder.
Fluent Python
Sous-titré : « Clear, Concise, and Effective Programming », de Luciano Ramalho.
Un livre fait avec beaucoup d’amour, bien que je ne sois pas allé au bout. Mon avis est donc biaisé.
Le livre est très bien écrit et aborde le fonctionnement interne de Python ; les méthodes spéciales, l’héritage en diamant, les classes abstraites, les comportements avancés des properties, les cas particuliers, etc.
La suite du livre (et c’est ce qui fait sa force) présente comment utiliser ce fonctionnement interne à son avantage pour faire des choses très précises (copier des objets de classes ayant plusieurs niveaux d’héritage).
J’ai tendance à considérer que ce type d’information sert surtout aux développeurs d’API ou de métaclasses (les deux allant souvent de pair, dans le cas des langages dynamiques).
Je connais des devs qui raffolent de ce genre discussion, et je comprends parfaitement dans quelles situations on ne peut pas s’en passer, mais dans le cas de mon travail, j’ai tendance à éviter de faire du code s’appuyant sur le fonctionnement interne de Python, car je le trouve plus difficile à maintenir.
Je recommande aux personnes qui souhaitent pousser plus loin les métaclasses.
Programmer efficacement en C++
Sous-titré : « 42 conseils pour mieux maîtriser le C++ 11 et le C++ 14 ».
Il s’agit de la version française de l’excellent « Effective Modern C++ » de Scott Meyers, sortis en 2014.
Un livre que j’ai eu du mal à terminer. Sans surprise, ce livre est destiné aux experts C++ qui sont à l’aise avec ces notions avancées ; lvalue, rvalue, etc. Il est complet, et la pédagogie de Scott n’est plus à démontrer.
J’apprends le C++ depuis des années, car il fait partie des langages systèmes les plus utilisés au monde, mais n’étant pas un expert et ne l’utilisant pas au quotidien, je me suis de nombreuse fois demandé si le chapitre que je m’apprêtais à lire allait vraiment m’apporter quelques choses par rapport à l’effort qu’impliquait la compréhension de base de son énoncé.
Je recommande aux experts C++ qui veulent aller plus loin.
Python Cookbook
Sous-titré : « Recipes for Mastering Python 3 ».
Celui-là, je l’ai adoré. Il montre comment résoudre des problèmes précis en expliquant à chaque fois les avantages, les inconvénients et comment aller plus loin. Les approches présentées peuvent être qualifiées de « pythonique » tant on finit par les utiliser mécaniquement dès qu’on se retrouve face à un de ces problèmes.
Les problèmes sont nombreux, le rythme est rapide (à peine quelques pages par problème) et touchent à pas mal de points du langage, ce qui donne un bon rapport entre le temps passé à lire ce livre et l’expérience qu’il apporte.
Je recommande à tout les pythoniste de niveau intermédiaire qui veulent monter en expérience rapidement sur le langage.
The Mythical Man-Month
Sous-titré : « Essays on Software Engineering », par Frederick P. Brooks Jr, sortis en 1975.
Si vous tapez du code sous contraintes depuis longtemps, vous avez forcément entendu parler de ce livre. Et pour cause, c’est sûrement le livre qui va le plus loin sur les limitations d’un modèle de développements strict et anticipé et sur la gestion d’une équipe de développement.
Le livre se présente sous la forme d’une relecture par l’auteur des difficultés rencontrées dans la gestion de différents projets informatique menés au long de sa carrière.
Ce qui est frappant c’est la minutie avec laquelle l’auteur décortique les problèmes rencontrés et comment les solutions issues de méthodes d’organisation dites « conventionnelles » peuvent influencer négativement le développement. Le recul pris par l’auteur sur son travail force l’admiration.
De nombreux détails techniques ont vieillis, mais il n’est pas surprenant que cet essai soit devenu un point de pivot dans l’évolution (la révolution ?) des méthodes d’organisation des projets informatiques. À la lecture de ce livre, il semble en effet difficile de justifier une organisation ne mettant pas les équipes de développement au centre. On ne peut comprendre l’évolution de la gestion de projet informatique sans avoir lu ce livre.
Si vous ne souhaitez pas lire ce livre, je vous recommande la très complète page Wikipédia.
Multithreading for Visual Effects
J’ai déjà écrit un avis détaillé de ce livre sur mon blog :
Dernière mise à jour : dim. 30 janvier 2022