Le développement logiciel en quelques livres
Tout peut s’apprendre par soi-même, mais une vie est trop courte pour faire toutes les erreurs possibles et en tirer les leçons. Je suis reconnaissant aux auteurs des ouvrages qui suivent d’avoir pris le temps de structurer l’expérience qu’ils ont tiré de nombreuses années de pratique, pour permettre à leurs lecteurs d’aller plus vite.
- Design Patterns: Elements of Reusable Object-Oriented Software, 1994, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (“Design Patterns”, “Gang of Four”, “GoF”)
Traduction française : Design Patterns: Catalogue de modèles de conceptions réutilisables
Ce catalogue de 23 patterns techniques jouit d’une renommée si grande qu’il n’est pas nécessaire de l’avoir lu pour être familier avec la plupart de ses patterns.
C’est une excellente introduction, claire et concrète, aux méthodes agiles. Bref, une lecture salutaire, surtout si vous n’avez jamais entendu parler que de SCRUM.
Le bon sens du programmeur. Cette lecture est relativement facile, c’est un bon point d’entrée.
- Clean Code: A Handbook of Agile Software Craftsmanship, 2008, Robert “Uncle Bob” Martin
Traduction française : Coder proprement
Le plus difficile n’est pas de produire du code à destination de la machine. L’essentiel, c’est que ce code soit maniable et s’accommode bien des inévitables évolutions des objectifs. Ce livre traite de manière très complète le problème de la maintenabilité du code informatique.
Extreme Programming (XP) n’est pas vraiment une méthode, mais plutôt un ensemble de pratiques parmi lesquelles une équipe technique peut piocher pour constituer sa propre méthode.
Non, le Test Driven Development (TDD) n’est pas une méthode de qualité logicielle. C’est une méthode de développement logiciel dont l’objectif poursuivi est d’accroître la productivité. Les tests ne sont qu’un sous-produit. Ce livre est une réfutation de l’hypothèse (largement répandue mais rarement assumée) que l’écriture des tests se fait au détriment du temps de développement.
Refactorer, c’est améliorer la structure interne d’un code sans changer son comportement apparent, par petites étapes élémentaires (sinon, on parle de “redesign”). Pour cela, il faut disposer d’un “harnais” de tests.
Ce livre contient à la fois un catalogue de patterns de haut niveau pour modéliser un domaine métier, et des outils pour penser l’articulation entre le “modèle” et son implémentation.
- Patterns of Enterprise Application Architecture, 2002, Martin Fowler
C’est un catalogue de patterns d’architecture (mais d’ailleurs, qu’est-ce que “l’architecture” ?). On y retrouve par exemple une description du pattern “Model - View - Controller”, appellation souvent utilisée mal à propos. Sa lecture est assez exigeante, je conseille de commencer par Domain-Driven Design.
Encore un autre catalogue de patterns d’architecture logicielle, souvent cité.
De l’énumération qui précède, on peut reconstituer l’histoire du génie logiciel des 30 dernières années. En premier lieu, on distingue la naissance puis l’évolution du mouvement agile, en opposition aux méthodes dites encore aujourd’hui “traditionnelles” (ou plus péjorativement, “en cascade”). La méthode du cycle en V est héritée des gigantesques projets de défense des puissances du bloc de l’Ouest¹. Au contraire, le mouvement agile tire sa source d’inspiration de l’Est : du Toyota Production System² élaboré à partir des années 50. La cohérence du mouvement est assurée par l’effort d’évangélisation des signataires du manifeste agile.
L’école des patterns est le deuxième mouvement incontournable du monde du développement informatique moderne. Les “patterns”, réunis en catalogues que le développeur garde à portée de main sur son bureau, sont des solutions générales à des problèmes rencontrés fréquemment. Ensemble, ils forment un langage commun à la communauté des développeurs. L’école des patterns reconnaît l’architecte Christopher Alexander comme son père spirituel. Elle doit néanmoins beaucoup à la communauté Smalltalk du Xerox PARC des années 80 dans laquelle elle se développe et acquiert sa renommée.
Sur ces 10 ouvrages, seuls 2 ont été traduits en français. On ne peut que constater l’importance de comprendre l’anglais technique pour pouvoir se référer aux sources originales.
Comme tous les vrais classiques, ces livres sont rarement lus, d’autant plus que les universités et les écoles n’en exigent pas la lecture. Le préjudice pour l’industriel logicielle est considérable : certaines pratiques (TDD, DDD par exemple) sont encore minoritaires. D’autres sont franchement dévoyées.
Notes
¹ Voir l’article wikipedia anglophone sur le cycle en V.
² Kent Beck revendique l’héritage du TPS dans Extreme Programming Explained
