Qu'est-ce que le développement pragmatique ? Retour sur le Forum PHP 2019

Presque tous les sièges de la salle sont occupés pour la première conférence du jour, traitant du développement pragmatique, présenté par Frédéric Bouchery.

Mais qu'est-ce que le pragmatisme mon cher Jamy ?

C'est acheter une Renault Espace plutôt qu'une Audit R8 lorsqu'on a 3 enfants. C'est donner une tablette à chacun d'entre eux lors du trajet des vacances, plutôt que de les laisser s’ennuyer et avoir droit toutes les 2 minutes à la sempiternelle question « Quand est-ce qu'on arriiive ? » (quoique l’on pourrait questionner aussi l’effet à long terme l’usage des supports digitaux pour les jeunes enfants).

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

De l'importance de structurer son code

Contrairement à une intelligence artificielle qui génèrerait tout son code dans un seul fichier sans que ça ne lui pose problème pour le maintenir et le faire évoluer, nous êtres-humains, n'avons pas la même vitesse de calcul.

« 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.

« Vous êtes votre futur legacy. » nous rappelle Frédéric, et c’est vrai ! Combien de fois repasse-t-on sur le code de notre ancien nous en se disant « 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 appliquent tous (ou essaient) d’appliquer des 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.

« DRY » : Don’t Repeat Yourself ; philosophie consistant à éviter la redondance du code.

« 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, ... » nous liste rapidement Frédéric, essoufflé...

Après toutes ces années de développement à essayer d'appliquer ces principes, il en est arrivé à la conclusion qu’il n’existe qu’un seul code parfait, sans bug et mettant tout le monde d’accord. Il nous livre son secret (il ne faut pas dire que je vous l’ai dit 🤐) :

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

Pourquoi faut-il revenir à l'essentiel

Et si on s’arrêtait 5 minutes et qu’on se posait 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 ? Pourquoi ne pas coder moins, mais de manière plus adaptée ?

Lorsqu’ils sont face à une problématique technique, Frédéric et son équipe se réunissent pour discuter des alternatives qui s’offrent à eux, puis utilisent une matrice de choix afin de déterminer quelle option est la plus adéquate. La solution gagnante est retenue collégialement, ce qui permet de mettre toute l’équipe en accord.

WET plutôt que DRY ?

Frédéric nous invite à nous poser des questions avant d’appliquer les principes précédemment évoqués et à trouver un juste milieu entre dogme et bénéfice.

Il prend pour exemple la bien connue philosophie DRY, consistant à éviter la redondance de code au sein d’une application afin d’en faciliter la maintenance, le test, le déboggage et les évolutions.

Il nous propose de s’intéresser à l’approche WET (Write Everything Twice). En effet, plutôt que de factoriser un code dès le premier copier/coller, ce concept nous recommande d’attendre une troisième répétition. Selon lui, cette approche permet de refactoriser plus efficacement, car on a à disposition plus de contextes d’usage.

Une invitation à la réflexion

En conclusion de sa conférence, Frédéric nous rappelle qu’une bonne pratique n’est pas une loi et est enfreignable. En fonction de l’utilisation, la dernière architecture à la mode n’est pas forcément la meilleure à appliquer.

Il faut essayer de d’adopter une approche pragmatique et d’appliquer la formule « moins de code, plus de réflexion, pas de hâte, pas de dogme ».

Crédit : Julien Pauli (@JulienPauli)