Note de lecture : More C++ Gems, Robert C. Martin edt.

Note : 4 ; Compilation hétéroclite

On oublie parfois que Robert Martin a été éditeur en chef de C++ durant plusieurs années ! Les articles regroupés ici sont la seconde fournée des morceaux choisis de plus de 10 ans de C++ Report ! Le premier volume était la sélection de Stanley Lippman, celle-ci vient d’un auteur ayant une sensibilité différente.

Le volume n’est pas anodin : il compte plus de 500 pages divisées en 2 parties inégales : la plus petite « diamonds from deep in the past » est la plus courte tandis que « Present day industrial diamonds » représente la portion congrue. Il y a 24 articles en tout, 6 dans la première partie et 18 dans la seconde.

Tout ne mérite pas le détour dans la première partie. Je passe très vite sur le « finite state machine » qui ne nous apprends pas grand chose, pas plus que l’article traitant des classes abstraites et de fonctions virtuelles pures. L’article de Cay Horstmann sur les smart pointers mérité définitivement plus d’attention car il traite de certains problèmes afférents à leur utilisation. A lire. De même « pointers vs references » c’est un peu du retour aux fondamentaux, mais c’est Stan Lippmann. Il faut toujours lire Stan Lippmann. L’article sur les NULL est rentré par une oreille et sorti par l’autre et la prose de James Coplien sur les patterns oublie d’être passionnante. On termine cette première partie par un article sur les patterns du regrété John Vlissides. Cela a à peine sa place ici, mais c’est tellement agréable à lire…

L’open-close principle qui ouvre la seconde partie du livre (et donc les 400 pages restantes) est bien, mais c’est du réchauffé, non seulement de C++ Report mais des propres livres de Robert Martin ! La prose de John Lakos qui suit est très longue. C’est même le monument de ce livre avec près de 90 pages, mais c’est à lire absolument. Il s’agit d’un condensé de son « large scale C++ design » et l’auteur nous y livre les stratégie de structuration de programmes pour gérer les dépendances, les temps de compilation ou de link. C’est passionnant et excellemment illustré !

Les deux articles qui suivent (taskmaster et monostate class) sont plutôt du domaine des patterns. Ils sont d’un intérêt assez moyen. Par contre celui sur les métriques ABC, sans être grandiose, nous propose une alternative intéressante au LOC. Ce n’est pas le cas du « patterns for mapping OO applications to relational database » qui est très léger et n’aurait pas dû figurer ici.

Heureusement, on arrive en terrain plus sérieux : avec Herb Sutter d’abord : les exception-safe container, c’est du lourd et on en a 30 pages ! L’anatomie de l’opérateur d’affectation, c’est du fondamental mais l’auteur creuse bien le sujet, parfait ! On est plus côté système (avec une pincée de patterns) sur cet article de Doug Schmidt sur les thread local storage. C’est du solide et ça ne se laisse pas lire comme ça. L’article de Matthew Austern sur l’exception safety fait écho à celui de Herb Sutter sur les exception-safe container. Bonne lecture aussi, j’approuve. A propos d’Herb Sutter, deux articles de cet auteur viennent à la suite. C’est du C++ pour les hommes, les vrais : lisez-les !

Je suis un peu désappointé de voir ici « external polymorphism » qui devient réellement un plat réchauffé plusieurs fois… Je passe rapidement sur le « safe deletion » qui a trait au multi-threading (mais pas terrible). Doug Schmidt, encore lui, nous parle de performances avec GPerf. Ce n’est pas de la lecture facile, hélas. L’ouvrage se conclut de nouveau par 2 articles d’Herb Sutter (à lire donc). Le second est un peu frustrant car il ne fait que 3 pages pour nous mettre l’eau à la bouche avec le langage BOOSE, une extension à C++. Mais hélas on n’en sait pas beaucoup à la conclusion de l’article !

Cette compilation manque un peu de cohérence. Il aurait fallu, à mon avis séparer les parties « pur C++ », la partie « patterns » et la partie « système ». Cela aurait déjà été plus clair. Le titre même de l’ouvrage est trompeur eut égard à la place importante consacrée aux patterns. Il aurait dû s’intituler : C++ and Patterns in C++ Gems. Bref, un problème de cohérence pour cette compilation qui se reflète dans la note. Comme je l’ai noté, il y a de bons articles, notamment ceux d’Herb Sutter, mais cet auteur a aussi ses propres ouvrages.

Bref, un ouvrage pas vraiment indispensable.

More C++ Gems

Référence complète : More C++ Gems – Robert C. Martin – SIGS books / Cambridge University press 2000 – ISBN: 0-521-78618-5

More C++ Gems

http://www.goodreads.com/book/add_to_books_widget_frame/0521786185?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Pattern Languages of Program Design vol. 3 – Robert Martin, Dirk Rhiele & Frank Buschmann edt.

Note : 8 ; Une compilation de patterns de très bonne qualité.

Ce troisième volume de la série PLOP-D a complètement redynamisé la série ! Alors que je reprochais aux volumes précédents la portion de matériel utile, il n’y a rien de tel ici : la substance utilisable directement dans nos projets y est importante. J’ai trouvé la sélection clairement orientée vers les patterns de conception, ce qui n’est pas pour me déplaire. Cependant, même les patterns organisationnels peuvent s’avérer utiles ou inspirants, tel que le “Patterns for pattern writters”. Malgré cette orientation, le volume est quand même découpé en plusieurs parties, en fait plus de parties même que les opus précédents, car on en compte 10 ici, mais elles sont aussi plus finement ciblées. Il était aussi question d’opérer un découpage valable pour un livre qui compte maintenant 575 pages.

La première partie traite des patterns à usage généraux. Cette première partie n’est certainement pas à ignorer. On y trouve le très utile « null object », l’excellent « extension object » qui est une des très rares contributions d’Erich Gamma. Le « manager » de Peter Sommerlad a plutôt une coloration historique, car c’est le pattern universellement utilisé aujourd’hui pour les DAO.

La seconde partie couvre des variations sur les patterns. Elle va d’avantage intéresser le praticien expérimenté. Les trois sont intéressants, les variations sur le state pattern peuvent être utilisées presque tel quel dans une formation.

J’ai trouvé les deux patterns architecturaux qui forment la troisième partie du même nom assez peu convainquants. Tant pis.

La quatrième partie est consacrée aux patterns liés aux architectures distribuées. Les 5 patterns qui la constituent sont plutôt musclés. Ma préférence va au très élégant « asynchronous completion token ». L’ « acceptor connector » vaut certainement le détour, mais il est quelque peu complexe et la présentation à l’aide diagramme en notation Booch n’aide pas.

Ce sont deux patterns qui constituent la cinquième partie consacrée à la persistance. Le « serializer » a surtout un intérêt documentaire, tandis que « accessing relational database » bien que bien construit n’offre plus qu’un intérêt mitigé aujourd’hui.

On ne trouve qu’un seul pattern dans la sixième partie qui cible les interfaces utilisateur. Il s’agit plutôt d’un pattern language d’ailleurs, mais je lui ai trouvé peu d’intérêt.

La septième partie traite de patterns de programmation et il ne faut pas la rater, même si elle ne contient que deux de ces patterns (presque des idiomes). Le premier d’entre eux est le désormais célèbre « double-check locking », tandis que l’« external polymorphism » qui s’apparente beaucoup au décorateur n’est pas dénué d’intérêt.

Je n’ai jamais vraiment été soulevé d’enthousiasme par les « business patterns ». Peu d’entre-eux trouvent grâce à mes yeux. Cette huitième partie en contient 3 et j’avoue qu’ils ne m’ont pas marqué.

On n’échappe pas facilement aux « process patterns ». Nous en avons 4 dans cette neuvième partie. Le « pattern for evolving frameworks » est un pattern language qui met bien en exergue les aspects fondamentaux de la conception d’un framework. Le « pattern for designing in teams » contient les frémissements de l’avènement d’XP. Le « pattern for system testing » est le plus intéressant du lot, à mon avis. Là encore un pattern language qui mérite la lecture.

Si vous vous sentez l’âme d’un auteur, le « pattern language for patterns writing » sera votre amis. Il est le seul membre de cette dixième partie consacrée aux « patterns on patterns ». Ecrire un pattern, le soumettre (et être accepté) en conférence n’est pas si simple, j’en ai l’expérience. Rétrospectivement, je trouve qu’il s’agit-là d’un bon guide.

On ne peut espérer un score de 100% de matière utile à une compilation de patterns issus d’une conférence. Cela dit la sélection est vraiment très bonne, c’est un très bon livre, je ne l’ai pas lu en pensant « vivement que cela finisse » que cela a été parfois le cas avant. Je garde précieusement ce volume et le recommande.

PLOPD-vol3

Référence complète : Pattern Languages of Program Design, vol. 3 – Robert Martin, Dirk Rhiele, Frank Buschmann edt. – Addison Wesley / Software Patterns series 1998 – ISBN: 0-201-31011-2

Pattern Languages of Program Design 3

http://www.goodreads.com/book/add_to_books_widget_frame/0201310112?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : Clean Code, par Robert C. Martin

Note : 6 ; Du (très) bon, mais hélas aussi du moins bon

Comme l’indique son nom, ce livre concerne l’écriture de beau code. Il rejoint en cela « implementation patterns » de Kent Beck ou « Refactoring » de Martin Fowler.

J’ai beaucoup apprécié les 10 premiers chapitres. L’auteur (ou les auteurs, devrais-je dire) y évoque en détail différents aspects d’écriture et de présentation du code.

Au chapitre 1 qui évoque le « pourquoi » de l’ouvrage, le chapitre 2 traites du nommage, ou comment le rendre pertinent et distinguable. Des aspects que l’on a trop souvent tendance à oublier.

Le chapitre 3 traite des fonctions, sujet important s’il en est. Bien sûr on y parle de la taille des fonctions et de leur lisibilité, mais aussi de la nécessité de concevoir les fonctions selon un seul niveau d’abstraction. Par contre l’idée de séparer l’interception d’exception ne tient tout simplement pas la route. Désolé.

Au chapitre 4 on aborde les commentaires. La règle est simple, le code doit principalement être lui-même le commentaire et ceux-ci doivent donc être réduits à la portion congrue. Le chapitre 5 concernant le formatage est plus surprenant, pourtant les conseils y sont bons, par exemple concernant l’espacement vertical.

On monte en niveau d’abstraction avec le chapitre 6 traitant des structures de données et le chapitre 7 évoquant les exceptions. Rappeler d’anciens principes tels que la loi de Déméter me semble aujourd’hui plus nécessaire encore qu’hier !

Les chapitres 8 et 10 traitent d’avantage de considérations de design. Si le contenu reste valable, le traitement du « 3rd party code » est quand même un peu simpliste. On ne saurait couvrir ce genre de problématiques en 15 pages et 2 conseils donnés à l’emporte-pièce. Les directives données sur la conception des classes rappellent celles issues du précédant livre de l’auteur : « agile software development ». Donc rien de nouveau.

Rien de nouveau non plus sur les tests unitaires évoqués au chapitre 9, bien que la lecture en soit plaisante.

En montant en niveau d’abstraction, les chapitres 11 à 13 qui traitent plutôt de problématiques d’architecture, voient un peu gros pour un traitement qui se révèle un peu court. Le chapitre 11 aborde l’intérêt de l’AOP par rapport à la conception de systèmes, mais il s’agit à peine d’une introduction même si l’on tente d’évoquer les mérites comparés d’Aspect J et de Spring AOP. Je n’ose même pas retenir le chapitre 12 traitant de l’émergence en 5 pages ou du chapitre 13 sur la concurrence qui ne saurait soutenir la comparaison avec l’ouvrage de Doug Lea. Même avec son chapitre complémentaire en annexe.

Les chapitres 14 à 16 sont des tutoriaux guidés de refactoring. Hélas, le format livre se prête mal à cet exercice qui se révèle rapidement rébarbatif. Un support interactif online serait bien mieux adapté.

Bref, j’ai bien apprécié 150 des 400 pages de ce livre. C’est insuffisant pour classer celui-ci dans les bons ouvrages, mais il vaut quand même un petit détour.

clean-code

Référence complète : Clean Code, a handbook of agile software craftsmanship – Robert C. Martin – Prentice hall / Robert C. martin series 2008 – ISBN: 0-13-235088-2 ; EAN: 978 0 13 235088 4

Clean Code: A Handbook of Agile Software Craftsmanship

http://www.goodreads.com/book/add_to_books_widget_frame/0132350882?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Clean Coder, A code of conduct for Professional Programmers par Robert C. Martin

Note : 8 ; Les enseignements de 40 ans d’expérience

Ce livre se veut la suite du « clean code » parut dans la même collection. L’approche de l’auteur y est différente, car il y parle de son expérience personnelle, de ses réussites mais surtout de ses échecs ! Ce livre, écrit sur le ton de la confidence est vraiment très agréable à lire. Le propos se rapproche beaucoup de celui du « pragmatic programmer » : que devez-vous faire pour vous comporter en vrai professionnel du développement ? J’avoue que je préfère le livre d’Andy Hunt et Dave Thomas, mais celui-ci apporte nombre d’enseignements avec lesquels je me sens en phase, même si uncle Bob vend ici son « software crafmanship » et qu’il s’agit somme toute d’un autre exercice tournant autour de son ego…

Le livre comporte 14 chapitres totalisant 185 pages. C’est donc un ouvrage assez court.

Les 3 premiers chapitres tournent autour de l’éthique du travail : qu’est-elle, quand doit-on savoir dire « non » et qui signifie réellement dire « oui ».

Les chapitres 4 à 7 sont focalisés sur le cœur des pratiques de développement. Certaines des idées mises sont curieuses, comme l’idée d’éviter l’état de concentration intense pour développer (le « flow ») ! Par contre l’idée de la pratique et des « coding dojos » sont elles, intéressantes.

Les chapitres 8 à 10 ont trait aux pratiques projet : stratégies de test, gestion du temps et des estimations. On n’y trouve pas grand chose de nouveau, du moins qui n’ait été développé ailleurs (dans les ouvrages de McConnell ou de Mike Cohn, par exemple). Mais le propos reste plaisant.

Enfin les chapitres 11 à 14 sont relatifs aux pratiques d’équipe : gestion de la pression, collaboration ou mentoring.

Le livre ne recèle pas d’apport nouveau. Il s’agit plutôt d’un condensé d’idées reprises d’ailleurs. Souvent synthétisées, par fois avec des raccourcis. Le livre conviendra aux praticiens agiles lisant peu, pour qui ce texte court et facile à lire donnera de nombreux pointeurs vers les différents sujets constituant le quotidien du projet, tout en donnant un guide pour ce qui est du professionnalisme du développeur.

clean-coder

Référence complète : The Clean Coder, A code of conduct for Professional Programmers – Robert C. Martin – Prentice Hall / Robert C. Martin series 2011 – ISBN : 978 0 13 708107 3

The Clean Coder: A Code of Conduct for Professional Programmers

http://www.goodreads.com/book/add_to_books_widget_frame/0137081073?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on