Informations générales
Ce livre a été écrit par Robert Martin, un vulgarisateur de la programmation et un développeur expérimenté. Il s'agit d'un ouvrage sur la manière d'écrire un code plus propre, plus compréhensible et plus correct. Examinons brièvement ce livre.
Résumé des chapitres
Le premier chapitre est totalement théorique et un peu sec. Il parle de l'importance d'écrire du bon code et de la façon dont le coût de maintenance d'un mauvais code augmente chaque mois — que ce soit en termes d'argent ou de temps.
Ensuite, il parle de la manière de mieux nommer les variables : les variables doivent transmettre l'intention du programmeur et, lorsqu'on lit une variable, il doit être clair de quel type de données elle contient. Il est mentionné qu'il faut éviter des noms abstraits comme List, Data, etc. La dénomination des méthodes et des classes est également abordée, bien que ce sujet fasse plutôt partie des chapitres suivants, où l'auteur en parlera plus en détail. Les conseils donnés sont nombreux et, dans l'ensemble, raisonnables et pratiques. D'un côté, il s'agit d'un chapitre très basique et évident, mais de l'autre, pour un débutant, cela pourrait être très utile.
Vient ensuite le chapitre sur les fonctions. Il s'agit d'un des sujets les plus controversés — combien de lignes une fonction doit-elle avoir, combien de paramètres doivent être utilisés. Évidemment, la réponse est évidente : plus la fonction est petite, plus elle est simple. Pourtant, dans la pratique, ce n'est pas toujours aussi simple. Le livre soulève également un point très raisonnable et judicieux : une fonction doit effectuer une seule action spécifique. Par exemple, une fonction ne doit pas calculer une moyenne et imprimer le résultat à l'écran en même temps. C'est un principe similaire aux principes SOLID. En outre, l'auteur discute également du traitement des conditions (if, else, switch), des boucles, et de la structure try/catch. Bien sûr, il parle aussi de la dénomination des fonctions et du principe DRY (Don't Repeat Yourself).
Ensuite, un chapitre sur les commentaires : comment et où ajouter des commentaires et quels endroits les commentaires sont superflus. Les commentaires légaux, journalistiques et autres types de commentaires sont analysés, et leur pertinence est examinée.
Si vous pensez que les commentaires sont un sujet controversé, que dire du formatage ? C'est le sujet du petit chapitre suivant. Si vous pensiez qu'il s'agissait simplement d'un problème de tabulations et d'espaces, vous vous trompez. Ce chapitre est bien plus riche en contenu. L'auteur fournit même des graphiques différents.
Le chapitre suivant parle des objets et des structures de données — il ne s'agit pas de développement en profondeur, mais plutôt de concepts tels que l'abstraction, la non-symétrie des données, le principe de Demeter, les DTO, les enregistrements d'activités, etc. Ce chapitre est relativement superficiel, les sujets étant déjà bien connus des programmeurs expérimentés.
Ensuite, nous avons un chapitre sur la gestion des erreurs. De nombreux exemples dans ce chapitre sont en Java, donc vous ne trouverez pas la gestion des erreurs de style Go (avec des instructions if), mais principalement le try/catch. Quelques chapitres plus tôt, le formatage était abordé, et maintenant il est question de quand, comment et où utiliser le traitement des exceptions.
Le chapitre suivant est intitulé "Les frontières" — il ne parle pas directement du code, mais davantage de l'architecture, en particulier de la composition et de l'utilisation des modules. Ce chapitre est assez court, donc pour ceux qui sont intéressés par l'approche de Robert Martin en matière d'architecture propre, il est conseillé de se référer à son livre sur ce sujet.
Ensuite, nous abordons les tests. Le TDD (Test Driven Development) est brièvement abordé, puis il est question des différents types de tests. Ce chapitre est relativement court et assez simple. Si les tests vous intéressent, je vous recommande un excellent livre, que je pourrais bientôt analyser en détail.
Les chapitres suivants concernent les classes. Si vous considérez les classes comme une partie intégrante du nettoyage du code (comme le fait l'Oncle Bob), alors ce chapitre peut suffire. Mais si vous souhaitez vraiment plonger dans la programmation orientée objet (POO), ce chapitre sera un peu insuffisant et peut-être difficile à suivre.
Les chapitres suivants abordent à nouveau l'architecture. Il ne s'agit pas de l'architecture traditionnelle à plusieurs niveaux, que Robert Martin recommande dans un autre de ses livres. Ici, il s'agit davantage de contenu de base. Le premier chapitre ressemble davantage à une explication de différents diagrammes qu'à du code. Il mentionne également quelques modèles de conception — usines abstraites, injection de dépendances, proxy, etc. Globalement, ces chapitres sont bons et informatifs.
Le chapitre suivant parle du multithreading. Il s'agit davantage de théorie que de pratique : il y a peu de code, et la discussion est assez superficielle.
Les chapitres suivants traitent du refactoring du code, l'auteur explique par ses propres exemples. Contrairement aux chapitres précédents, ceux-ci contiennent plus de code. Tout d'abord, l'auteur parle du refactoring des outils en ligne de commande, puis analyse quelques bibliothèques/classes Java, toutes issues de développeurs expérimentés. Même ces experts, Robert Martin réussit à trouver des choses à critiquer — ce que je considère plus comme de la critique pointilleuse que comme un véritable refactoring. Après tout, même ce code fonctionne correctement et est bien couvert par les tests. Le point clé de ce chapitre est que coder un code fonctionnel ne suffit pas — il doit aussi être maintenable, sinon avec le temps, cela deviendra une tâche extrêmement difficile.
Le dernier chapitre est une conclusion, qui résume les conseils de tout le livre : des annotations aux fonctions et aux tests.
Conclusion
Avantages du livre
- La structure du livre est bonne, avec 17 chapitres qui se complexifient progressivement. En d'autres termes, lorsque l'on apprend un langage de programmation, on commence par les bases (variables, commentaires) puis on passe progressivement aux fonctions, aux classes, à la programmation asynchrone, etc. Le livre suit une approche similaire, ce qui est à la fois pratique et familier.
- La plupart des conseils sont très utiles et logiques. Certains trouveront beaucoup de nouvelles informations, tandis que d'autres n'apprendront probablement rien de nouveau. Cela dépend de l'expérience du lecteur.
- Le livre contient des illustrations. Elles ne sont pas nombreuses, mais même celles qui existent sont cohérentes et plaisantes à regarder.
Inconvénients du livre
- Il ne faut pas suivre aveuglément tous les conseils. Il y en a au moins quelques-uns, voire plusieurs, avec lesquels je ne suis pas entièrement d'accord ou que je trouve carrément erronés.
- Le livre lui-même est assez volumineux — plus de 450 pages. Cela peut être un peu difficile à lire pour certaines personnes.
- Les exemples de refactoring du code (ajout et suppression de lignes) pourraient être mieux présentés. Actuellement, les modifications sont indiquées en gras (ajouts) et en barre oblique (supprimés), mais peut-être qu'un marquage à la manière d'un client Git serait plus clair.
- Les exemples du livre sont principalement en Java. Je n'ai rien contre cela, ni de problèmes de compréhension, mais pour ceux qui ne sont pas familiers avec ce langage, cela pourrait être un inconvénient.
- Je lisais la version de 2010. Il peut y avoir une version mise à jour. La version que j'ai lue est un peu dépassée. Elle aurait pu non seulement être mise à jour, mais aussi complétée.
Évaluation générale
Ce livre est vraiment un best-seller dans le domaine du développement de logiciels. Il mérite au moins une lecture rapide, et de préférence une lecture approfondie. Si vous n'avez pas le temps ou l'intérêt de lire le livre entier, je recommande au moins de jeter un œil aux résumés de chaque chapitre et aux conseils généraux dans le dernier chapitre. Une fois terminé, il peut être utile de discuter des méthodes et des conseils avec des collègues, car suivre aveuglément les conseils de Robert Martin pourrait ne pas toujours être approprié et parfois même incorrect.
