The world is changing, and I believe that, if I want to stay employed as a programmer, I’m going to have to change with it.
Kent Beck
Étiquette : craftsmanship
Note de lecture : Seriously Good Software, par Marco Faella
Note : 4 ; Le “seriously” est à prendre très au sérieux !
Ce texte n’est pas très facile à classer entre Java et Craftsmanship. S’il est résolument orienté sur la plateforme Java, c’est tout de même sur les principes d’implémentation (et un peu de conception) que l’auteur met l’accent. L’auteur, parlons-en, est professeur d’informatique à l’université de Naples. De fait, sans en avoir l’austérité, le texte a quelques ressemblances avec un support de cours.
Voyons un peu ce qu’il en est. L’ouvrage compte 9 chapitres répartis sur 2 parties très inégales, pour un total de 280 pages. On le voit, ce sont des chapitres relativement conséquents, en moyenne supérieur aux 20 pages par chapitre qui m’a toujours semblé un bon compromis. La première partie compte deux chapitres, couvrant 45 pages. Le chapitre introductif traite de la qualité ou plus exactement des qualités attendues d’un logiciel. Ce seront les points successivement développés dans les chapitres suivant, puis l’étude de cas qui nous suivra tout au long de l’ouvrage est introduite.
Le second chapitre introduit l’implémentation de référence. Une implémentation qui ne cherche à optimiser ni la performance ni l’emprunte mémoire. Toutefois l’approche adoptée pour analyser l’un et l’autre est présentée ici, grâce à cette version facilement appréhendable. Bien sûr c’est la notation O popularisée par la STL qui est utilisée pour les performances. On sent déjà le côté « support de cours » dans ce chapitre par ailleurs pas désagréable à lire.
Lire la suiteNote de lecture : Unit Testing : Principles, Practices and Patterns, par Vladimir Khorikov
Note : 8 ;Des principes et des guidelines très solides pour concevoir les tests unitaires et les tests d’intégration.
Ce n’est pas le premier ouvrage sur les tests unitaires, bien loin s’en faut ! Mais c’est une belle surprise, même si elle bouscule un peu certaines de mes idées établies sur le sujet. Le but de l’auteur est de faire émerger et poser les principes sous-jacents à la pratique des tests unitaires. On pourrait penser que cela peut se contenter d’un mémoire de 50 pages au plus ? Il n’en est rien.
Au niveau du format, le livre rentre dans la moyenne : 270 pages sur 11 chapitres, le tout divisé en 3 parties inégales. . La première d’entre-elle nous dresse le paysage des tests unitaires sur un peu plus de 60 pages incluant 3 chapitres. La finalité des tests unitaires est l’objet des 20 pages du premier chapitre. C’est un début en douceur où est évoqué la question de l’entropie du code, mais où l’auteur s’attaque surtout au mythe de la couverture de code (à juste titre). Dommage que le mutation testing ne soit pas évoqué, ni ici ni plus tard.
Le second chapitre s’attaque à des principes fondamentaux : qu’est-ce qu’un test unitaire ? Une question moins simple qu’il n’y parait. Outre la granularité délimitant le test unitaire des tests d’intégration ou de bout en bout, c’est surtout le choix de l’école de pensée qui est en cause : école de Londres (parfois appelés tests solitaires) ou école classique ou de Chicago (parfois appelés tests sociaux). L’auteur ne fait pas mystère de sa préférence pour l’approcha classique, mais fait un excellent travail pour déterminer comment chaque approcha traite les différents types de dépendances. Le chapitre s’attaque à l’anatomie interne des tests unitaire. Il n’est guère surprenant que l’auteur fasse la promotion du pattern AAA (Arrange, Act, Assert). Il va plus loin en détaillant les bonnes pratiques sur chacun des volets pour améliorer la lisibilité et la maintenabilité des tests, pour ensuite adresser la question de leur paramétrage.
Note de lecture : The Pragmatic Programmer 20th anniversary edt., par David Thomas & Andrew Hunt
Note : 8 ; Le changement dans la continuité
La lecture de la première édition fut une réelle révélation pour moi. C’était à l’époque, la prémices de ma découverte de l’agilité. Aujourd’hui ce texte symbolise plutôt le craftsmanship, mais la différence entre les deux a-t-elle tant de sens ? Guère pour moi, en tout cas.
Beaucoup de choses ont changé dans le détail du contenu, d’une part parce que certaines idées des auteurs ont évolué (ce qu’ils soulignent régulièrement dans le texte même) et d’autre part car à la fois le contexte technologique et les pratiques ont progressé. Je pense, sur ce dernier point, aux pratiques de test.
Cette édition 20ème anniversaire a pris un léger embonpoint : 283 pages contre 259 pour l’édition précédente, passant de 8 à 9 chapitres. Dans votre bibliothèque, la couverture dure de ce nouvel opus va le faire passer dans la catégorie de standing supérieur. Les fameux « tips » qui parsèment le livre passent quant à eux de 77 à 97 ! Le premier chapitre s’intitule toujours « a pragmatic philosophy » et compte 25 pages couvrant 7 sujets. Il couvre en peu de pages un ensemble de comportements : prendre ses responsabilités, ne pas laisser les choses se dégrader et entretenir son portefeuille de connaissances. Une belle introduction.
Note de lecture : Refactoring, Improving the design of existing code 2nd edt., par Martin Fowler with Kent Beck
Note : 8 ; Petit dépoussiérage d’un sujet toujours aussi important !
Pas moins de 20 ans ont séparé les deux éditions de cet ouvrage ! Le refactoring, c’est un peu la clé à molette de l’architecture émergente. Et ce livre en est le manuel officiel. Autant dire que c’est un ouvrage majeur du monde agile en général et du craftsmanship en particulier.
Cette seconde édition semble moins imposante que la première. En fait, elle compte approximativement le même nombre de pages, à savoir un peu plus de 400 hors annexes. Question de papier… Petite nouveauté toutefois : il existe une version en ligne qui est la version de référence et qui inclut la totalité des refactorings. La version papier en est donc un sous-ensemble. Toutefois l’ouvrage contient le code d’activation de cette version en ligne qui n’est pas en libre accès ! Autre petite différence, l’impression en 4 couleurs, privilège accordé à un grand classique, j’imagine…
Le livre totalise 12 chapitres, dont les 6 derniers constituent le catalogue à proprement parler. Autant prévenir tout de suite, les exemples sont en JavaScript, ce qui est franchement une mauvaise nouvelle pour moi. L’auteur nous a promis des exemples sans idiomes spécifiques, ce qui est vrai à quelques exceptions près.
Le premier chapitre est un teasing du livre, un exemple. Il met en œuvre des refactorings successifs en identifiant à chaque étape les « smells » résiduels. Il le fait avec la pédagogie à laquelle il nous a habitué. Et il est vrai que le JavaScript ne gêne guère. Un plaisir. On rentre dans le dur au chapitre 2, avec 35 pages consacrés aux principes du refactoring. On y explique quoi, quand et surtout pourquoi refactorer. La pratique y est inscrite au sein des pratiques d’XP et surtout comme partie intégrante du design émergent. J’y retrouve tout ce qui m’avait emballé il y a un peu plus de 20 ans. Cela avait été une révélation pour moi, avant même que je découvre l’agilité. Ne ratez pas ce chapitre.
Note de lecture : Java by Comparison, par Simon Harrer, Jörg Lenhard & Linus Dietz
Note : 6 ; Craftsmanship, niveau junior
Le code de qualité, il faut bien commencer à l’écrire un jour. Et ce jour, ce peut être sur les bancs de l’université. C’est ce qui a motivé en premier lieu l’écriture de ce texte. Contrairement aux classiques du Craftsmanship qui s’adressent au développeur aguerri, celui-ci s’adresse au débutant et la progression des chapitres reflète cela.
C’est un texte assez court, qui n’excède pas 165 pages et compte 9 chapitres au long desquels sont distillés 70 exemples, toujours présentés de la même façon : une page avec le code « avant » auquel fait face le code « après » sur la page en vis-à-vis, agrémenté de quelques explications, mais le tout contenu dans ces deux pages. Le premier chapitre adresse des basiques de clarté du code, sur une vingtaine de pages, soit 8 exemples, qui vont des formulations booléennes à la notion de symétrie du code. Tout cela reste très simple, mais nécessaire à couvrir pour le débutant. On remarquera toutefois une approche « opiniated » qui persistera tout au long du livre, mais cela me semble normal.
On passe la seconde avec le second chapitre. Cela continue sur des questions de clarté, par exemple avec les énumérations, mais aussi de code sain, notamment à propos des itérations. Tout ceci est couvert en 8 exemples également. Alerte maximum pour le chapitre 3 dédié aux commentaires ! Ce sont même 10 exemples qui figurent ici. Mais, oh soulagement, les 4 premiers nous suggèrent d’éliminer les commentaires redondants. Finalement on fait dans le bon sens.
Note de lecture : Software Design X-Rays, par Adam Tornhill
Note : 5 ; De la difficulté d’écrire une suite à un livre qui sort du lot !
C’est vrai, « Your code as a crime scene » m’avait laissé pantois : utiliser le gestionnaire de version comme une machine à remonter dans le temps (ce qu’il est, en fait) nous avait fait découvrir de nouvelles façons de regarder le code, d’en tirer des informations et des enseignements. Ce volume se veut le prolongement de cette nouvelle manière de penser. Malheureusement, comme nous allons le voir, il tombe un peu court pour cela.
Le succès du volume précédant a donné un petit extra à cet opus-ci : il est imprimé en couleur. De fait, ses 210 pages (hors annexes) contiennent moult illustrations. La structure du livre compte 10 chapitres également répartis sur deux parties. La première d’entre-elle s’intitule « prioritize and react to technical debt » et couvre environ 90 pages. Elle s’ouvre sur un premier chapitre d’une douzaine de pages pour nous expliquer pourquoi la dette technique n’est en fait pas technique ! Le propos de l’auteur est de nous amener à comprendre que la dette technique est en fait de la dette organisationnelle et qu’il est nécessaire de se focaliser sur les parties de code qui ont le plus fort « taux d’intérêt ». L’idée est intéressante, mais le propos est loin d’être direct et bien que j’adhère au propos, je suis loin ici de la révélation.
Justement, le second chapitre nous conduit vers la notion de code à fort taux d’intérêt. Il nous en coûtera une vingtaine de pages. Cette notion, l’auteur la calcule en combinant la fréquence de changement avec la complexité du code. Certes le chapitre développe un peu cela, mais je n’y trouve rien d’extraordinaire. Le chapitre 3 développe une notion déjà abordée dans le livre précédant : les « co-changing files », ou couplages temporels entre fichiers n’ayant pas de dépendances ! Si l’auteur s’étend plus sur les causes et remèdes, je n’y trouve pas non plus d’effet de découverte.
Note de lecture : Clean Architecture, par Robert C. Martin
Note : 5 ; Agréable à lire, mais beaucoup de “recyclage », beaucoup de verbiage et peu d’information nouvelle.
Robert Martin est sans contestations possibles un des maîtres du craftsmanship. Je l’ai découvert avec son « C++ Applications Using the Booch Method » qui fut un régal. Son « Clean Code » et plus modestement son « Clean Coder » ont popularisé le craftsmanship et les concepts SOLID. Il m’est difficile d’avouer que j’ai eu du mal à trouver ici des idées nouvelles par rapport à ses écrits précédents. L’ouvrage atteint les 370 pages mais ce volume me parait être là pour donner le change.
Ainsi la première partie composée de 2 chapitres ne dit pas grand-chose, si ce n’est qu’il ne faut pas faire de concession sur la qualité de l’architecture. Une position pas vraiment nouvelle de la part de l’auteur.
La seconde partie fait partie des éléments nouveaux apportés par Uncle Bob : elle est consacrée aux paradigmes des langages de programmation et est composée de 4 chapitres, soit un peu plus de 35 pages. L’auteur nous présente ces paradigmes comme autant de contraintes, de possibilités que l’on enlève au programmeur pour chacune d’entre-elle :
Note de lecture : Your Code as a Crime Scene, par Adam Tornhill
Note 8 ; De nouvelles perspectives sur l’analyse du code en utilisant une machine à remonter le temps !
J’avais entendu parler de ce livre, en bien… mais j’avais aussi entendu quelques réserves à son égard. C’est sans doute ce qui a retardé sa lecture, et c’est bien dommage ! A part son titre surprenant, le livre n’est remarquable de prime abord que par son impression en couleur. A titre personnel, j’ajoute aussi la préface par Michael Feathers.
Le volume compte moins de 190 pages, annexes comprises. Il n’en est pas moins découpé en 15 chapitres dont 14 sont rassemblés en 3 parties. Le chapitre d’introduction ne servant guère qu’à expliquer la démarche générale du livre.
La première partie « evolving software » regroupe 5 chapitres sur un peu plus de 50 pages. Le premier chapitre « code as crime scene » donne le ton dans tous les sens du terme. D’abord par le titre qui reprends celui du livre, mais aussi en ouvrant sur l’histoire de Jack l’éventreur et des informations extrapolées des lieux de ses méfaits. De la même manière l’auteur identifie les « hot spots » de logiciels par les endroits ayant subi le plus de changements, en exploitant la gestion de version. L’exploitation de la dimension temporelle sera un dénominateur commun de beaucoup des analyses qui nous seront proposées.
Note de lecture : Beyond Legacy Code, par David Scott Bernstein
Note : 4 ; Beaucoup de verbiage et peu d’illustration
Une nouvelle déconvenue, je dois bien l’avouer. Non pas que le style de l’auteur soit mauvais, il est plutôt tonique avec de bonnes qualités de « story telling ». Non pas qu’il n’ait rien à dire, bien au contraire : il transparait du texte une maîtrise, une compréhension et une solide vision de son sujet. Non, l’auteur échoue à développer convenablement son sujet, à l’appuyer sur de solides exemples. Au lieu de cela, il semble préférer discourir en se servant du texte comme une tribune. Pourtant le contenu est au coin de la rue, il ne demande qu’à se révéler : ce sont les 9 principes qui constituent l’essence de l’ouvrage.
L’ouvrage, justement n’est pas excessivement volumineux, avec ses 230 pages. Mais attention : il s’agit exclusivement de texte ! Il est découpé en 2 parties très inégales, la première servant d’introduction avec 3 chapitres sur 40 pages, la seconde développant les 9 pratiques sur le reste du livre.
La première partie s’ouvre sur le triste constant du code legacy et de ses causes : une industrie d’amateurs comme le dit l’auteur. Rien de vraiment neuf, mais c’est bien écrit et guère ennuyeux. Le second s’attaque sur une douzaine de pages au fameux CHAOS report, mais de façon critique, ce qui est assez original, et pertinent en l’occurrence. Mais c’est aussi pour dire qu’il partage les conclusions, mais pas l’analyse. Enfin cette 1ère partie se referme sur un petit chapitre introductif à la seconde partie (les 9 pratiques) et comme quoi notre focus sur l’agile nous a fait perdre de vue la nécessité de solides pratiques de conception (ou d’ingénierie) qui en forment les fondations. Je suis bien d’accord.
Software Freethinker 