Étiquette : craftsmanship

Note de lecture : New Programmer’s Survival Manual par Josh Carter

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Manque de ciblage clair

Sur le papier, le public cible de ce livre est claire : donner au jeune développeur arrivant dans la vie professionnelle une boite à outil pour lui permettre d’acquérir plus rapidement les bonnes habitudes et les bons comportements. C’est pourquoi les 225 pages de cet ouvrage au format inhabituel, plus proche du roman que du livre informatique dont nous avons l’habitude, sont découpés en 33 « tips ». Jusqu’ici tout va bien. En fait, cela ressemble au format emprunté par son ainé, le « pragmatic programmer ». Bonne également, l’idée de découper l’ouvrage en 4 parties :

  • Professionnal programming : 14 tips sur 2 chapitres, couvrant près de 100 pages, donc pas loin de la moitié du livre.
  • People skills : 9 tips sur presque 50 pages et toujours 2 chapitres.
  • Corporate world : Les deux chapitres composant cette partie regroupent 6 « tips » sur presque 50 pages aussi.
  • Looking forward : clos le texte avec 3 tips sur un seul chapitre.

Les conseils toutefois, quand on rentre dedans semblent un peu disparates. C’est sans doute pour cela que l’auteur à attribué 3 niveaux de maturité aux conseils qu’il prodigue : ceinture blanche, ceinture marron et ceinture noire. De mon point de vue c’est l’erreur fondamentale du livre. Au lieu de cibler le débutant l’auteur tente d’adresser différents publics et finalement ne satisfait correctement aucun d’entre-eux. C’est dommage car l’auteur écrit fort correctement et son savoir-faire et la pertinence de ses idées est réelle.

Le livre a voulu cibler trop large en parlant à différents publics, mais aussi en élargissant son débat depuis le craftmanship jusqu’aux aspects sociaux dans l’entreprise. On se trouve ainsi avec du code (Ruby) en début d’ouvrage et des questions sur les cycles de développement produit vers la fin. Ce n’est pas une diversité qui me choque en soi, mais j’ai du mal à y trouver une cohérence dans le propos.

En lisant ce livre, je n’ai pu m’empêcher de le comparer à « SQL antipatterns ». Ce dernier réussit là où celui-ci échoue. En effet ce premier à choisit délibérément de s’adresser au développeur souvent peu expert (et peu intéressé) par les questions ayant trait aux bases de données et à la modélisation de celles-ci. Je pense que ce « new programmer’s survival manual » aurait dû atteindre la qualité du « SQL antipatterns » en ciblant son public et surtout en maintenant sa cible dans son contenu et aurait peu et dû atteindre le même niveau de satisfaction.

C’est donc une déception.

new-prog-survival-manual-pragprog

Référence complète : New Programmer’s Survival Manual, Navigate your workplace, cube farm or startup – Josh Carter – Pragmatic Bookshelf 2011 – ISBN : 978-1-93435-681-4

New Programmer's Survival Manual: Navigate Your Workplace, Cube Farm, or Startup

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

Note de lecture : SQL Antipatterns, par Bill Karwin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Au croisement des préoccupations du développeur et du concepteur de base de données

Le pluriculturalisme est un véritable problème en informatique. Prenons le cas qui nous intéresse aujourd’hui : comment concilier le point de vue (valide) du concepteur de base de données, avec les questions d’efficacité d’accès aux données, de normalisation du modèle et de requêtage SQL, avec le point de vue tout autant valide du développeur s’adossant à cette même base de données, pour qui celle-ci n’est qu’un support de persistance ? La réponse est : ces points de vue sont rarement conciliés. En cela ce livre est réellement intéressant car il considère ensemble ces deux points de vue tout au long de nombreux cas de figure de conception de modèles de données constituant autant d’antipatterns. On notera aussi au passage que les exemples sont toujours donnés avec MySQL, toutefois lorsque des spécificités de certains SQBD s’appliquent, l’auteur en fait part.

Le texte est articulé autour de 24 antipatterns constituant autant de chapitres. Leur structure est invariable : objectif, antipatterns, comment le reconnaître, usages légitimes et solution. Cette structure qui montre une bonne appréhension du principe des patterns s’avère très efficace, aussi bien dans le diagnostique du problème que dans l’émergence de la solution. Ces patterns se répartissent par ailleurs en 4 parties dans l’ouvrage.

La première partie est constituée de 8 antipatterns occupant 100 pages ! Elle traite de la structure logique de la base. On y parle de l’usage irraisonné de champs blob, du bon usage des contraintes et des cardinalités (entre autre lorsqu’il faut user de tables intermédiaires). Ces règles paraissent de bon sens aux vieux routiers de la modélisation, mais elles sont souvent enfreintes par les développeurs d’applications peu enclins à passer beaucoup de temps et d’attention sur le modèle et donc prêts à « couper les virages » !

La seconde partie traite de la structure physique de la base. Elle compte 135 pages et 4 antipatterns. On y évoque l’usage intelligent des différents types de champs, mais aussi de clés primaires et d’index secondaires pertinents. Là encore, il s’agit des éléments de base du DBA … qui devraient l’être aussi pour le développeur. Mais l’expérience montre…

Dans la troisième partie (6 patterns, 60 pages) on évoque les requêtes, le bon usage de la valeur « null », des regroupements, mais aussi de l’écriture des « requêtes à tout faire ».

La dernière partie est longue de 6 patterns couvrant 70 pages. On trouve ici diverses bonnes pratiques applicatives pour couvrir par exemple des problèmes de sécurité. Hélas les exemples sont développés en PHP, bien loin de ce que je ne saurais utiliser (aussi bien sur le langage que sur l’architecture). C’est donc le chapitre qui m’a le moins intéressé.

En lisant ce livre j’ai eu l’impression (non la certitude) de lire des choses que je connaissais déjà. Mais j’ai eu aussi l’impression de croiser des cas de figure que j’ai vu appliqués plus ou moins souvent, mais que j’ai tous vu ! J’en conclu que cette lecture devrait faire partie du bagage de tout développeur applicatif, aussi basique que semblent parfois ces concepts ! Le ciblage de l’ouvrage est clair : il s’adresse aux développeurs qui va souvent considérer la base de données comme un artefact de second ordre, un simple moyen de persistance des données qu’il va traiter dans son application.

La vérité est qu’appréhender l’association d’un développement objet (au hasard) et d’une base de données, c’est devoir faire face à la question des paradigmes multiples. Ce livre est original à ce titre car il fait face à cette réalité et va aider le développeur souvent peu sensibilisé à ce problème à monter en compétence.

De plus le texte est clair et bien écrit. Pourquoi se priver de cette lecture ?

sql-antipatterns-pragprog

Référence complète : SQL Antipatterns, Avoiding the pitfalls of database programming – Bill Karwin – Pragmatic Bookshelf 2010 – ISBN : 978 1 93435 655 5

SQL Antipatterns: Avoiding the Pitfalls of Database Programming

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

Note de lecture : The Art of Readable Code, par Dustin Boswell & Trevor Foucher

Le par addinquydans Notes de lectureLaisser un commentaire

Note 3 ; Le contenu est bien maigre…

Je m’en doutais un peu dès le départ en le tenant en main : le contenu serait vite lu. Ce fut bien le cas. Je pensais y trouver des éléments de style auxquels confronter mes propres idées, le bilan est pour le moins mitigé sur ce point. Au départ, l’ouvrage compte 180 avec une structure plutôt aérée et des cartoons humoristiques comme on aimerait en voir plus souvent. L’ensemble est découpé en 15 chapitres, eux-mêmes regroupés en 4 parties. Disons que c’est un bon point de départ.

La première partie « surface level improvements » compte 6 chapitres sur 60 pages. Elle ne parle que de choses simples, pourtant je l’ai trouvée plutôt pas mal. Les sujets qui y sont traités sont principalement nommages, indentation (et mise en page au sens large) et commentaires. J’adhère à beaucoup des idées, mais pas toutes. Les développements autour des commentaires sont probablement les plus intéressants que j’ai pu lire.

La seconde partie « simplifying loops and logic » est développée sur 3 chapitres totalisant un peu moins de 40 pages. On y parle ici de lisibilité du code via le découpage des méthodes ou la simplification des expressions. Certains sujets sont à la limité des questions de lisibilité et touchent plutôt la qualité. Les points abordés le sont bien, mais le sujet n’est plus neuf car il est le pain quotidien des pratiquants du refactoring.

En troisième partie « reorganizing your code », c’est en 35 pages sur 4 chapitres que les auteurs traitent du refactoring à plus grande échelle. La lecture et les exemples sont loin d’être palpitants et l’on peut même dire que le traitement du sujet en est largement superficiel. On préfèrera nettement la lecture du « refactoring to patterns » de Joshua Kerievsky à ce sujet !

La troisième partie « selected topics » est forte de 2 chapitres couvrant 30 pages. Le premier traite de la testabilité et de l’écriture des tests unitaire, là aussi un sujet bien mieux traité dans de nombreux ouvrages, tandis que le chapitre suivant est une sorte d’étude de cas qui ne restera pas gravé dans ma mémoire.

Au final, on peut considérer que ce livre est une sympathique, mais peu consistante distraction. Les illustrations qui émaillent le livre ajoutent à l’agrément. Il reste bien léger et à part les aspects traitant des commentaires, je n’en garderais pas grand chose. Vous pouvez passer votre chemin.

art-readable-code-oreilly

Référence complète : The Art of Readable Code, Simple and practical techniques for Writing better code – Dustin Boswell & Trevor Foucher – O’Reilly 2011 – ISBN : 978-0-596-80229-5

The Art of Readable Code

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

Note de lecture : The Pragmatic Programmer: From journeyman to master, par Andrew Hunt & David Thomas

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; Think! About your work; Book of the year (ex-æquo) 2002

Pensez! Mais pensez à la façon dont vous travaillez! Tel pourrait être le credo des auteurs de ce livre. Cet ouvrage ne traite pas de processus de développement logiciel à proprement parler, il expose plutôt une façon de se comporter et d’appréhender le développement logiciel au quotidien.

L’activité de développement logiciel est-elle un travail systématique décrit par des règles rigides? A cela les auteurs répondent: non! Ils abordent d’ailleurs le travail du développeur d’avantage comme l’activité d’un artisan que comme un travail d’ingénierie. Bien loin d’être un parallèle défavorable, il faut y voir une valorisation de notre travail, quand pour chaque problème il faut chercher une solution réfléchie, pragmatique et adaptée. Certains l’auront déjà compris, c’est d’agilité dont nous parlons ici ! Publié en 2000, il ne s’agit pas là d’une adhésion tardive à un effet de mode, mais au contraire le fruit de réflexions de « véritables croyants ». D’ailleurs Hunt et Thomas sont parmi les signataires originaux de l’agile alliance.

Le livre se découpe en 8 chapitres qui regroupent au total 70 « tips » (il y a un aide mémoire avec le livre).

Chap 1 : Pragmatic philosophy. On nous enseigne ici les lignes directrices de l’agilité : le « juste assez », l’entropie du logiciel, …

Chap. 2 : Pragmatic approach. Ce chapitre traite des tactiques de réalisation : la « balle traçante » ou le langage du domaine, par exemple.

Chap. 3 : Basic tools, traite de l’environnement, outils d’édition, de build ou de génération de code. Bref, c’est pour l’usine logicielle !

Chap. 4 : Pragmatic paranoia (là, c’est pour moi) nous enseigne l’anticipation des comportements erronés.

Chap. 5 :Bend or break, traite de conception (donc de patterns) et de sa bonne mise en œuvre.

Chap. 6 : While you are coding évoque tout ce qui gravite autour de l’implémentation : les tests, le refactoring, etc…

Chap. 7 : Before the project, car il ne faut pas confondre vitesse et précipitation ! On parle ici de spécifications, mais aussi des travers qui peuvent en découler.

Chap. 8 : Pragmatic projects, évoque la dimension stratégique du projet : la gestion des tests, le cycle itératif, etc…

Ne vous y trompez pas: ce livre ne vous expose pas comment programmer. Il existe pour cela d’autres ouvrages dédiés aux langages de programmation, par exemple. Une partie (importante) du texte est toutefois dédié à des aspects de conception générale: programmation défensive, méta programmation, architecture MVC.

Mais pour moi l’intérêt principal du livre n’est pas là. Son intérêt principal est de nous montrer que la responsabilité d’un ingénieur de développement ne se limite pas à écrire du code. Notre responsabilité est de livrer un développement dont nous pouvons être fiers, de qualité et répondant aux réels besoins utilisateur. Un travail que nous pourrions même signer: fruit d’une élaboration sérieuse, robuste, bien écrit et convenablement documenté. Un travail professionnel, réalisé par un vrai professionnel, un “pragmatic programmer”.

Ai-je oublié de vous dire que je recommande fort chaudement cet excellent ouvrage ? Mais notez au passage le vocabulaire plutôt riche employé dans le texte, qui peut en rendre la lecture légèrement difficile.

pragmatic-programmer

Référence complète : The Pragmatic Programmer: From journeyman to master – Andrew Hunt & David Thomas – Addison Wesley 2000 – ISBN: 0-201-61622-X

The Pragmatic Programmer: From Journeyman to Master

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

Note de lecture : Debug it ! Find, Repair & Prevent Bugs in Your Code, par Paul Butcher

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; Dommage qu’on y parle si peu de debug …

S’il est une facette du développement considérée comme peu noble, c’est bien le debug ! L’évolution des pratiques de développement tendent à réduire considérablement la part de debug nécessaire (entre autre via les tests unitaires) et c’est une bonne chose ! Toutefois la maîtrise de cet art reste une compétence nécessaire (où je n’ai pas la sensation d’exceller), c’est donc avec bonheur que j’ai accueilli ce nouvel ouvrage, cautionné par le sérieux des « pragmatic programmers » !

Je vais immédiatement casser le suspens en avouant de but en blanc que j’ai été fortement déçu.

La première partie est dédiée à la décomposition du processus de correction, avec un chapitre consacré à chaque phase du processus, soit 4 chapitre plus un chapitre de présentation, pour un total de 85 pages (sur 200). Le processus est simple et bien connu : reproduire, diagnostiquer, corriger, réfléchir (ou s’interroger plus exactement). Je ne suis pas un expert en correction de problèmes pourtant je connais (et pratique) cela depuis fort longtemps, aussi je pense que cette partie s’adresse au débutant. Too bad !

La seconde partie « biger picture », est longue de 25 pages découpée en 2 chapitres. Elle replace la correction de bugs dans un contexte plus large : les interactions avec les utilisateurs une équipe support, la remontée aux sources du mal (pourquoi avons-nous des bugs).

La troisième partie « debug fu » est la plus proche de ce que je considère comme le sujet du livre. Elle couvre 4 chapitres sur 85 pages. Les 20 pages du chapitre 8 « spécial cases » sont même au cœur du sujet. J’aurais espéré voir ce thème développé plus longuement, alors que le chapitre 9 consacré au « debuging environnement » parle de tout sauf d’environnement de debugging !

Au final, ce livre s’est fixé un but : décrire comment travailler (et avec quoi travailler) pour ne plus avoir besoin de debugger. En fait, je suis d’accord avec cet objectif. Mais je pense que les sujets attenants sont déjà traités par ailleurs et dans plus d’un livre ! Et mieux ! Et il arrive un moment où il faut bien sortir de sa boite à outil un savoir faire de debugage, car c’est ce dont on a un besoin. Et là ce livre ne réponds pas présent, alors que c’est là où je l’attendais, sur un domaine abandonné par tous les auteurs.

Mon conseil, et il est exceptionnel eut égard à la qualité du « pragmatic Bookshelf » : évitez ce livre !

debug-it-pragprog

Référence complète : Debug it ! Find, Repair & Prevent Bugs in Your Code – Paul Butcher – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 628 9

Debug It!: Find, Repair, and Prevent Bugs in Your Code

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

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 : JUnit recipes, par J.B. Rainsberger & Scott Stirling

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Un peu de déchets, mais beaucoup de matière, souvent aussi utile qu’originale.

Ce livre est pratiquement un livre de patterns d’utilisation de JUnit, donc à rapprocher de l’ouvrage de Mezzaros. L’ouvrage est imposant avec ses presque 700 pages. Heureusement, il n’est pas nécessaire de les lire linéairement.

Les deux premiers chapitres sont consacrés aux classiques B.A. BA de JUnit, on en est débarrassé en 70. Vient ensuite la vraie substance.

Les deux chapitres suivants (les 3 et 4, donc) ont un focus plus original, car ils traitent de l’organisation des tests, en terme de package ou de projet (avec ou hors du code de production), puis de l’organisation des suites de tests. Ce sont, pour la plupart, des questions réccurentes auxquelles il est rarement répondu. Le chapitre 5 suit logiquement en évoquant l’exécution des tests pilotée par les données. Bien évidemment, DbUnit est évoqué, mais aussi Ant avec ses tâches SQL. On a donc droit à un propos assez large.

Les chapitres 6 et 7 ont d’avantage trait à l’execution et au reporting des tests. Bien entendu, cela couvre l’extension du framework JUnit pour le reporting. La première partie se conclut par un chapitre dédié aux problèmes fréquemment rencontrés, je ne suis hélas pas en mesure de jauger sa pertinence.

La seconde partie est consacrée aux tests J2EE. Si on couvre quelque peu le XML et les pages HTML, les tests sur JDBC se taillent la part du lion. A l’heure de JPA, d’Hibernate ou JDO, je me pose quand même des questions, pour ne pas parler du chapitre consacré aux EJBs ! De la même façon, si le chapitre sur les tests des composants Web paraît utile, on n’évoque guère que JSP et Servlets, quid des JSF et autres Struts. D’ailleurs un chapitre est consacré aux tests de navigation où aucuns de ces frameworks (Struts, WebWorks, etc..) n’est évoqué ! Quand à parler de Spring… Bref, je suis déçu par le contenu de cette partie, même si il reste affuté techniquement.

La troisième partie porte sur des sujets complémentaires, où l’on traite des cas de figures non classiques : listeners, singletons, etc… Très utile, autant qu’original.

Bref, un livre de ressources utiles que l’on fera bien d’avoir sous le coude pour performer sur les tests unitaire : Il y a clairement beaucoup de matière ici.

junit-recipes

Référence complète : JUnit recipes, practical methods for programmer testing – J.B. Rainsberger & Scott Stirling – Manning 2005 – ISBN : 1-932394-23-0 ; EAN : 9 781932 394238

JUnit Recipes: Practical Methods for Programmer Testing

http://www.goodreads.com/book/add_to_books_widget_frame/1932394230?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

Le par addinquydans Notes de lectureLaisser un commentaire

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