Qu’est-ce que le développement pragmatique ?

Le développement pragmatique est une approche du développement informatique privilégiant le bon sens et l’expérience du terrain face aux dogmes techniques. L’idée centrale est de développer son esprit critique pour faire des choix mesurés selon le contexte de son projet, plutôt que d’appliquer mécaniquement les bonnes pratiques de développement « à la mode ».

Inspiré par la conférence de Frédéric Bouchery lors du Forum PHP 2019, cet article explore cette philosophie où le code parfait n’existe pas, mais où le code utile fait la différence.

Qu’est-ce que le pragmatisme mon cher Jamy ?

Le pragmatisme, c’est par exemple acheter une Renault Espace plutôt qu’une Audi R8 lorsqu’on a 3 enfants. C’est aussi donner une tablette à chacun d’entre eux pendant le trajet des vacances, plutôt que d’avoir droit toutes les 2 minutes à la sempiternelle question « Quand est-ce qu’on arriiive ? ».

En bref, le pragmatisme c’est se baser sur son expérience pour mettre en place, non pas la solution parfaite, mais celle qui fonctionne réellement.

Pourquoi structurer son code est essentiel

Contrairement à une intelligence artificielle capable de traiter de gros volumes d’informations sans s’y perdre, nous, êtres-humains, avons besoin d’organisation. Structurer son code facilite sa lecture, sa maintenance et son évolution.

N’importe quel imbécile peut écrire du code qu’un ordinateur peut comprendre. Les bons programmeurs écrivent du code que les humains peuvent comprendre. Martin Fowler

Nous devons structurer notre code pour qu’il soit compréhensible par les autres développeurs, de débutant à senior, et par notre futur nous. Eh oui, car nous sommes notre futur legacy ! Combien de fois repasse-t-on sur le code de notre ancien nous en nous demandant « Mais quel est le débile qui a écrit ça ? Ah, c’est moi... ».

Le code, c’est comme les blagues, si on doit l’expliquer, c’est qu’il est mauvais ! Cory House

Il y a tellement de principes à expérimenter lorsque l’on code. Chacun d’entre eux promettant un code plus maintenable et évolutif que l’autre.

Trop de règles de programmation tue la programmation !

Les développeurs cherchent à appliquer les principes de « bonne programmation », avec certaines règles illustrées par de jolis acronymes, tels que « SOLID » (Single responsibility | Open/closed | Liskov substitution | Interface segregation | Dependency inversion), représentant les cinq principes de bases pour la programmation orientée objet. Jusque-là, tout le monde suit.

Mais il existe aussi « DRY » (Don’t Repeat Yourself), une philosophie consistant à éviter la redondance du code.

Et toute une floppée d’autres comme « Demeter law, Calistenic, East-Oriented, Hollywood principle, Else-less, Comment-less, DDD, TDD, KISS, YAGNI, TU, CI, AOP, OOP, Immutable, Strict-typed, Cyclomatic complexity, Dependency injection, Design by contract, Fail fast, Defensive programming, Loose coupling, High cohesion, Composition over Inheritance, CQRS, ... ». Ça comment à faire beaucoup 😵.

Après plusieurs années d’expérience à essayer d’appliquer tous ces principes, nous développeurs, arrivons à la conclusion qu’il n’existe qu’un seul code parfait, sans bug et mettant tout le monde d’accord. Le voici :

Et oui, le code parfait ne fait rien, car il n’existe tout simplement pas !

Recentrer la réflexion sur l’essentiel

Et si on s’arrêtait 5 minutes pour se poser les bonnes questions ? Pourquoi ne pas designer une solution selon l’expérience de chaque développeur de l’équipe ? Au lieu de mettre des barrières, pourquoi ne pas laisser les développeurs choisir ce qui leur correspond le mieux, afin de coder de manière plus adaptée ?

Face à une problématique technique, l’équipe peut se réunir pour discuter des différentes options, et utiliser une matrice de choix afin de déterminer quelle option est la plus adéquate. La solution retenue est ainsi collégiale, ce qui permet de mettre toute l’équipe en accord.

Un exemple : WET plutôt que DRY ?

Avant d’appliquer à tout prix les principes précédemment évoqués, essayons de trouver un juste milieu entre dogme et bénéfice.

Prenons par exemple la philosophie DRY, consistant à éviter la redondance de code au sein d’une application afin d’en faciliter la maintenance. On peut la nuancer avec l’approche WET (Write Everything Twice), qui nous recommande d’attendre une troisième répétition, plutôt que de factoriser un code dès le premier copier/coller. Cette approche permet de refactoriser plus efficacement, car on a à disposition plus de contextes d’usage.

Une invitation à la réflexion

En conclusion, rappelons qu’une bonne pratique n’est pas une loi et est enfreignable. En fonction du contexte, la dernière architecture à la mode n’est pas forcément la meilleure pour votre projet.

Crédit image : Julien Pauli (@JulienPauli)

Essayons plutôt d’adopter une approche pragmatique en appliquant la formule « moins de code, plus de réflexion, pas de hâte, pas de dogme ».

Alors à votre tour, allez-vous vous poser la question « Ce principe est-il adapté à mon contexte ? » sur votre prochain projet ?

Crédit photo : scyther5