Revue du livre Java by Comparison chez The Pragmatic Programmers

Présentation générale

Java by Comparison est un livre publié par Simon Harrer, Jörg Lenhard, et Linus Dietz, sorti en avril 2018 aux éditions Pragmatic Programmers et constitué d'un peu plus de 200 pages.

Résolument tourné vers la pratique, il constitue un recueil d'exemples de code mettant en lueur des bonnes pratiques. Les auteurs enseignant à l'Université, ont progressivement constitué un ensemble d'extraits de code illustrant des erreurs assez récurrentes constatées auprès de leurs étudiants.

Le parti pris des auteurs a donc été de constituer un ensemble de leçons illustrées par du code avant / après (70 échantillons) pour sensibiliser le lecteur à des smells et lui identifier des axes d'amélioration en réécrivant le code en recourant à un ensemble de bonnes pratiques. Plutôt que de se concentrer sur une introduction théorique des concepts, les auteurs introduisent ces concepts par des exemples concrets permettant de visualiser leur valeur ajoutée.

L'ouvrage, qui s'adresse avant tout à un public débutant ou ayant déjà fait ses premières armes en Java, est reconnu parmi les 100 meilleurs livres de tous les temps sur Java sur le site de recommandations BookAuthority

Le code source illustrant le livre est disponible gratuitement en ligne.

Une (des) histoire(s) de bonnes pratiques

Sur suggestion par l'un des auteurs, Simon Harrer, j'ai pris connaissance de ce livre dans sa version eBook, et propose ici une revue de son contenu.

La forme

Même si je n'ai pas eu un livre physique entre les mains, je vais m'attacher à restituer quelques éléments autour de la forme employée par les auteurs de l'ouvrage.

En premier lieu, tout a été fait pour permettre au lecteur une lecture efficace :

• Les exemples de code avant / après sont disposés de manière à avoir l'un (avant) sur la page de gauche, l'autre (après) sur la page de droite, facilitant la comparaison et donc la compréhension
• De nombreuses références et liens (cliquables dans la version eBook) complètent le propos et renvoient vers des sites ou ouvrages spécialisés pour permettre au lecteur d'approfondir un sujet par une voie plus conventionnelle
• Il y a de nombreuses références croisées au sein du livre, signe que les astuces et bonnes pratiques peuvent parfois se cumuler
• Chaque chapitre est introduit par une citation inspirante
• Pour ceux qui souhaiteraient avoir une lecture moins linéaire, un index assez fourni permet de retrouver la ou les pages évoquant un sujet donné

Le style de présentation rend la lecture très dynamique et il est très facile de rester concentré sur un exemple / apprentissage dans la mesure où il va mobiliser rarement plus de 4 pages.

L'ensemble se présente ainsi comme un ouvrage soigné, ce qui est un écho satisfaisant aux messages véhiculés par le livre sur les aspects qualité du code.

Le fond

Le sous-titre de l'ouvrage est Become a Java Craftsman in 70 Examples, cela illustre le positionnement du livre sur une thématique qualité plutôt qu'une thématique Langage/API. On y trouve également quelques éléments qu'on pourrait classer dans le thème de l'algorithmique, référence étant notamment faite aux Lois de De Morgan.

En tant que développeur expérimenté, bien évidemment la majorité des exemples faisaient déjà partie de mon référentiel. Ceci étant dit, j'ai quand même pris plaisir à relever quelques astuces / recommandations qui viennent le renforcer ou que j'ai eu plaisir à lire, je cite :

• valider les paramètres d'une méthode en suivant le même ordre que leur apparition dans la signature de celle-ci
• combiner état et comportement sur un objet pour ne pas subir le syndrome des objets anémiques et des couches services

Un élément qui m'a manqué est lié à la pratique de tests. Bien que mise en avant dans le propos et la démarche, je m'attendais à trouver une batterie de tests au sein du code source dont l'effet escompté serait de favoriser la mise en pratique. En effet, comment savoir si nos idées d'amélioration sur le code sont satisfaisantes, à minima n'entraînent pas de régression sur le scénario étudié, sans tests ? La mise à disposition de tests permettant de s'essayer à améliorer / corriger le code "avant" aurait je trouve de la valeur.

Sur le même registre qualitatif autour des exemples, je pense que mettre en ligne le code sur un dépôt en ligne de type Git (note : ayant posé la question à Simon dans l'interview, c'est désormais chose faite sur https://github.com/javabycomparison/samplecode) avec par exemple une branche reprenant la solution rendrait la lecture par le code, voire la mise en oeuvre de tentatives de réécriture, plus agréable et efficace.

Malgré ces axes d'amélioration qui ne concerne pas l'ouvrage directement mais plutôt ses compléments, le propos dans le livre est toujours très clair et les explications pertinentes. Les thèmes retenus sont pertinents, bien qu'on trouvera toujours à redire sur l'un ou l'autre exemple qu'on aurait trouvé pertinent de voir illustré (je pense notamment au cas des exceptions qui, même si elles sont couvertes, auraient pu l'être davantage à mon goût).

Ceux qui n'ont pas encore eu l'occasion de se familiariser avec les éléments de langage introduits avec Java 8 trouveront dans Java by Comparison matière pour mettre le pied à l'étrier. En effet, plusieurs chapitres (notamment les 5 - Prepare for Things Going Wrong - et 8 - Let Your Data Flow) intègrent ce qu'on désignera par les nouveautés de Java 8.

Les chapitres 1 à 4 vont davantage concerner les débutants et constituer quelques rappels pertinents pour les développeurs plus agguerris, alors que les chapitres 5 à 8 vont plutôt s'adresser à un public averti et permettre au lecteur de confronter son référentiel de pratiques / croyance aux conseils et recommandations des auteurs.
Enfin, le chapitre 9 - Prepare for the real world, avec un format un peu différent, complète l'ensemble avec des éléments de sensibilisation plutôt transverses touchant à la fois à la qualité du code et à celui du processus de préparation à la production. Sur ce dernier chapitre, si les outils classiques d'analyse statique sont répertoriés, une sensibilisation à quelques métriques qualimétriques comme la complexité cyclomatique, la détection de duplication, ou encore le code coverage, me paraissent manquer. Ce chapitre n'est pas en reste puisqu'il met également le doigt sur la thématique de la journalisation des logs, thème auquel j'imagine que les auteurs pourraient probablement consacrer un chapitre entier s'ils décidaient de l'approfondir.

Interview de Simon Harrer, co-auteur du livre

Simon a accepté de jouer à l'exercice de l'interview et je l'en remercie. Il est à noter que ma revue a été rédigée (non retouchée hors renvois) entre la transmission des questions et la lecture des réponses.

Eric

Peux tu te présenter en quelques phrases ? Que fais tu au quotidien, notamment quand tu n'écris pas un livre et as du temps pour toi ?

Simon

Bien sûr, j'ai 32 ans et je vis dans une petite ville dans le sud de l'Allemagne avec ma merveilleuse femme et notre fille qui a un an. Je travaille comme consultant senior pour INNOQ. Depuis août dernier, je fais partie d'une équipe qui développe des logiciels dans le cadre d'un projet client de commerce électronique utilisant[Remote Mob Programming] (https://www.remotemobprogramming.org). Du point de vue technologique, j'écris surtout des microservices basés sur Spring Boot. Dans mon temps libre, j'aime passer du temps avec ma famille, faire du ski et partir en randonnées. Quelques fois par an, je me lance dans des quêtes épiques avec mon groupe de jeu de rôle. J'aime bien également partir de temps en temps pour un week-end ailleurs et découvrir une autre ville européenne. Ces voyages surprises me permettent de recharger mes batteries et de le changer les idées tout en découvrant un autre mode de vie.

Eric

Si on ne compte pas ce que vous aviez déjà comme matière quand vous avez décidé d'écrire le livre, avez-vous une idée du temps cumulé à 3 jusqu'à la sortie de la version papier ?

Simon

Nous n'avons pas vraiment compté le temps que nous avons passé à écrire le livre. Toutefois, je sens que cela prenait vraiment beaucoup de temps pour le rédiger. Concrètement, Linus et moi nous sommes rencontrés pendant dix jours pour des ateliers intenses pendant lesquels nous avons élaboré le code en programmation en binôme. Il a donc fallu plus de 160 heures au total pour trouver les exemples de code. La rédaction de la première ébauche a pris environ deux heures, mais je pense que nous avons consacré au moins huit heures à la révision. Si l'on additionne ces chiffres, on obtient une limite très inférieure de ce que nous avons réellement investi dans ce livre. Disons que ça a pris du temps. :-)

Eric

Combien de temps s'est-il écoulé entre la décision d'écrire le livre et sa sortie en version papier ?

Simon

Il nous a fallu un an (13 mois pour être exact) pour soumettre l'idée du livre à l'éditeur et tenir la version papier entre nos mains. L'idée du livre est née un peu plus tôt, parce qu'il faut beaucoup de temps pour faire une bonne proposition de livre. Je suppose que c'était un an et demi au total.

Eric

Comment vous êtes vous organisés à 3 pour la rédaction du livre, et quels ont été les priorités pour que ce travail collectif forme un ensemble homogène ?

Simon

Nous avons déjà écrit des articles scientifiques ensemble et nous avons travaillé auparavant en collaboration sur des projets open source. Nous avons également utilisé ces pratiques pour le livre. Ainsi, les extraits de code dans le livre ont été créés en programmation par paires et revus par le troisième auteur plus tard. En ce qui concerne le texte, nous nous sommes rendus compte que l'écriture en binôme ne fonctionnait pas bien. L'un d'entre nous a donc rédigé l'ébauche initiale du projet de texte et les deux autres l'ont révisé et édité. Ainsi, chaque bout de code et de texte est passé dans les mains de chacun d'entre nous au moins une fois.

Eric

Comment et pourquoi avoir publié chez PragmaticProgrammers ?

Simon

Nous avons tous lu le livre The Pragmatic Programmer d'Andy Hunt et Dave Thomas, et utilisé quelques-uns des autres livres de Pragmatic dans nos cours à l'université comme Programming Concurrency on the JVM de Venkat Subramaniam ou Pragmatic Unit Testing in Java 8 with JUnit de Jeff Langr. Nous aimons beaucoup le style de ces livres et les trouvons très accessibles. Nous avons tout simplement envoyé notre proposition de livre à PragmaticProgrammers. Et deux jours plus tard, ils nous ont offert un contrat de livre et nous ont fait un retour sur notre proposition. Nous étions ravis d'une telle réponse rapide et détaillée, et pour être honnête nous n'avons pas songé à approcher d'autres éditeurs.

Eric

Aviez vous d'autres idées de titre pour le livre ?

Simon

Trouver un titre pour un livre est vraiment difficile. Le problème avec le titre Java by Comparison, comme il s'est avéré, c'est que certaines personnes avec qui j'ai parlé m'ont dit qu'elles ne sont pas très familières avec Java et ne pensent pas que le livre soit utile pour eux. Et à première vue, ils semblent avoir raison. Tous les exemples du livre sont en Java et quelques éléments sont spécifiques à Java. Le regardant de plus près, la plupart des choses s'appliquent à n'importe quel langage de programmation. Donc peut-être que quelque chose comme "Clean Code by Comparison" aurait été mieux. Néanmoins, si je pouvais, je le renommerais "Cleaner Code by Comparison" car un code propre sonne tellement absolu et j'ai plutôt cette notion relative qu'il est plus propre (lire meilleur) qu'avant. C'est cette idée d'améliorer le code en petites étapes qui est à l'origine du livre.

Eric

Avez vous trouvé l'inspiration dans d'autres livres pour la façon d'écrire  votre livre / le présenter ? Peut-être des habitudes / recommandations fournies par l'éditeur PragmaticProgrammers ?

Simon

Je pense que les livres qui nous ont le plus influencés sont Effective Java de Joshua Bloch avec son style d'article et Refactoring de Martin Fowler pour ses grands noms des refactorings. Les comparaisons que nous avons écrites suivent un style d'article et nous avons passé beaucoup de temps à discuter du bon nom pour chaque comparaison, notamment parce que Martin Fowler a montré que les bons noms pour les refactorings sont mémorisés. L'autre inspiration vient de David Heinemeier Hansson qui a écrit sur ce sujet indiquant que ce que grâce à une comparaison avant/après qu'on pouvait s'en faire la conclusion si le code était vraiment meilleur. Sans une telle comparaison, tout n'est que des paroles en l'air. C'est essentiellement de là que vient cette mise en page de deux pages, avec le code sur le côté gauche et un meilleur code sur le côté droit pour que le lecteur puisse comparer. Nous avons aussi beaucoup appris de notre rédacteur en chef et de l'éditeur. Écrire un livre est vraiment un travail d'équipe. L'habitude la plus importante que nous ayons apprise est que le fait d’avoir besoin de rétroaction autant que possible. L’idée derrière est : plus vous avez de critiques pendant que vous écrivez encore, plus le livre s'améliore. Nous sommes très reconnaissants envers nos vingt réviseurs techniques qui nous ont aidés à avancer, à remettre en question nos écrits et nos idées et à nous donner encore plus d'idées sur quoi écrire.

Eric

Y-a-t-il une bonne pratique décrite dans le livre que tu as apprise à l'occasion de l'écriture, prise de recul aidant ?

Simon

Les comparaisons elles-mêmes, je les enseigne déjà depuis six ans à l'Université de Bamberg. Je n'ai donc pas beaucoup appris sur les particularités de la programmation. Cependant, j'ai appris à me concentrer sur ce qui est important, et j'ai appris à mieux communiquer le pourquoi des améliorations proposées au code. Parce qu'il n'est pas toujours si facile d'expliquer pourquoi un code est mauvais et pourquoi l'autre est un peu meilleur, compte tenu de la disposition en deux pages qui limite notre espace pour le code et le texte.

Eric

Dans la mesure où le code illustrant le livre est disponible en libre téléchargement, y-a-t-il une raison de ne pas le proposer en ligne sur un espace type Github/Gitlab/Bitbucket ?

Simon

Excellente question. Ton souhait a été pris pour un ordre et je l'ai ajouté sur https://github.com/javabycomparison/samplecode après avoir pris ta question :-)

Eric

Si c'était à refaire, concernant Java by Comparison, que referais-tu à l'identique ? Que changerais tu ?

Simon

Je changerais seulement le titre en "Cleaner Code by Comparison" (sans sous-titre probablement). Sinon, je suis très satisfait du cheminement et du résultat, et j'y rajouterai peut-être une témoignage ou référence venant de Martin Fowler.

Eric

Envisagez vous une suite au livre ? 2ème édition ? Autre publication (...) by Comparison ?

Simon

J'aimerais faire une deuxième édition. Nous avons déjà pensé à une dizaine de comparaisons sur Java Concurrency qui n'ont pas été intégrées dans la première édition. Et depuis la sortie du livre, Java 11 et maintenant même Java 12 a été publié avec de nouvelles fonctionnalités de langage et APIs. Lors de la conférence JAX 2018, j'ai rencontré Brian Goetz et je lui ai demandé de jeter un coup d'œil au livre. Il nous a donné un bon aperçu des comparaisons qui pourraient bénéficier des prochains changements Java prévus dans Java 12 et ses versions ultérieures. Nous avons donc déjà un bon plan pour la deuxième édition. Le seul problème, c'est le temps... nous devons tous les trois trouver le temps de le faire. Cet obstacle est beaucoup plus dur à surmonter que l'écriture elle-même. Le concept "par comparaison" a vraiment du potentiel non seulement pour les langages de programmation mais aussi pour d'autres choses. Effectivement, je pense d’appliquer ce concept au niveau du framework, comme un Spring Boot by Comparison.

Eric

Y-a-t-il des projets de traduction ? En allemand ? ;-)

Simon

Il y en a un. Un éditeur sud-coréen a acheté la licence pour la version coréenne. Mais je n'ai pas d'écho si cette version de notre livre est arrivée sur les étagères là-bas. J'aimerais bien faire une traduction allemande, même française. Mais j'adorerais faire tant de choses... :-)

Conclusions

De par sa taille que les auteurs ont souhaité garder à un volume inférieur à la moyenne, c'est un livre qui se lit assez facilement. Personnellement, j'ai joué le jeu de le lire de façon linéaire, mais il est parfaitement possible d'en avoir une lecture par chapitre en portant son intérêt sur une thématique particulière.

Quant à savoir si la promesse illustrée par le sous-titre est atteignable, les auteurs expliquent bien que sa simple lecture n'est pas suffisante et qu'il est nécessaire de la compléter par de la pratique, je pense en effet que c'est un bon début (surtout quand je vois parfois la qualité du code produit par des développeurs pourtant agguerris sur le papier) mais que l'ouvrage ne couvre pas l'ensemble des compétences permettant d'être un bon craftsman Java. Cependant, je pense qu'un tel ouvrage n'existe pas et qu'il n'est pas réaliste de l'imaginer, chose que les auteurs assument très bien en faisant la promotion d'autres livres Java pour compléter leur propos.

Java by Comparison est un livre d'une très bonne qualité, avec un soin particulier apporté sur la forme, qui permettra à tout développeur Java de confronter son référentiel de pratiques non seulement aux bonnes pratiques mais aussi aux bonnes pratiques du moment (cf. évolutions apportées au langage). Il est à conseiller à toute personne soucieuse de la qualité du code. Ne vous y trompez néanmoins pas, son focus est principalement sur le langage et éléments du JDK, agrémenté légèrement de quelques librairies / outils, et il ne vous apprendra pas les bonnes pratiques avec les multiples librairies et frameworks composant votre stack technique (à quand donc un Spring by Comparison ?). En cela, il est principalement à conseiller à un public débutant, mais reste un bon investissement pour aider à engager des discussions et pousser à l'amélioration une équipe de développement, soit un bon atout pour un dévelopeur senior ou lead dévelopeur qui cherche des outils pour sensibiliser ses collègues à la qualité du code.