Je n’ai jamais autant le sentiment de faire mon boulot de dév que quand je supprime du code. Et pourtant, l’attachement au code est la barrière la plus difficile à surpasser pour aider mes collègues à adopter une culture d’ingénierie, c'est à dire de l’expérimentation. Pour une raison que je ne comprends pas, ou en tout cas plus (peut-être ai-je eu aussi cet attachement, je ne me souviens pas), les développeurs aiment leur code, chaque ligne de ce code, depuis la première minute de son existence. Et plus on en a écrit, plus on s’y attache.
Qualité
Les organisations doivent s’adapter rapidement aux besoins. Les sociétés évoluent. Les gens grandissent, leurs besoins changent. Notre compréhension de ces besoins et de notre environnement de travail s’affine. On ne peut pas geler le monde pendant les mois ou années que nécessite le développement d’un produit.
Notre métier est de modifier du code. Nous avons donc besoin d’un code suffisamment plastique pour s’adapter à ces changements. C’est, dans une activité de résolution de problème comme le dév, ce que j’appelle la qualité: la capacité à soutenir un rythme satisfaisant sur la durée voulue. Pour être agile, cette capacité, la qualité, est non négociable. C’est notre devoir, en tant que dev, de la mettre en oeuvre, en permanence, sans demander l’autorisation de personne.
Conception
Cette plasticité du code, on la trouve dans les patterns, dans la modularité, dans la forte cohésion et le faible couplage, etc. Mais il faut savoir qu’à chaque fois qu’on fait un choix de pattern, on fait un compromis, on rigidifie un axe pour en assouplir un autre.
Prenons le principe DRY (Don't Repeat Yourself, ne te répète pas). Il est universellement admis comme un principe de base. Je n'entends presque jamais ce principe discuté. Pourtant, il participe à créer des dépendances, source du mal. C'est donc déjà un compromis à comprendre. On ne met pas le code en commun sans y réfléchir. Et ce n'est pas parce que la syntaxe de deux morceaux de code se ressemble que c'est le même code. Pensons sémantique avant de mettre du code en commun. Martin Fowler a popularisé la règle de trois, qui suggère d'écrire un code trois fois avant de la factoriser. Neal Ford nous apprend que "plus quelque chose est réutilisable, moins il est utilisable". J'ai découvert récemment l'acronyme WET, comme Write Everything Twice (écrit tout deux fois). Ne restons pas bloqués sur le DRY, et réfléchissons aux compromis.
Les design patterns sont également des compromis à comprendre. Ils favorisent la plasticité selon un axe en en sacrifiant un autre. Par exemple, et la provocation est volontaire, l'héritage permet de multiplier facilement le nombre de représentants d'une classe de comportement donnée. Mais il fige la vision externe de ce comportement.
Même quand on ne voit pas quel axe on fige, il faut être conscient qu'un pattern est une indirection. Or, les indirections sacrifient la lecture des détails, au profit de la vue d'ensemble. On scanne mieux les grandes lignes, et moins les détails. C'est un compromis, qui a des avantages et des inconvénients. Il faut en être conscient.
Frugalité
Ma première piste, pour rendre le code plus malléable, est de ne pas l’écrire. Le code le plus simple à modifier est celui qui n'existe pas. J’essaie de n’ajouter que le code dont j’ai besoin, de n’introduire des indirections que quand elles apportent de la valeur, de supprimer le code quand il n’apporte pas plus de valeur que le coût de sa complexité.
Notez que nous avons des outils à notre disposition pour limiter la quantité et la complexité du code:
-
Avec le TDD, on n'écrit que le code qui permet de faire passer un test, pas plus.
-
Avec le DDD, on divise le problème en bounded contexts. Chacun de ces contextes est ainsi de plus petite taille. Comme on ne met pas de code en commun entre ces contextes, on limite les dépendances et donc la complexité.
-
Avec le BDD, le contour du problème est mieux cerné. On évite les hypothèses inutiles.
Quel bonheur de refactorer un code vide. On appelle ça greenfield, et ça fait briller les yeux des nerds de tous âges. C'est un extrême, qui donne une idée des conséquences d'y tendre: sérénité, bonheur, sourires.
Si vous voulez vous approcher de cet idéal, limitez la quantité de code à modifier:
-
n'écrivez pas de code au cas où "on" en aurait besoin
-
ne posez pas de design patterns tant que la complexité du code n'en justifie pas le besoin
-
n'anticipez pas trop les besoins de flexibilité du code. Attendez de voir selon quelle dimension le code a besoin de bouger
-
pour supporter tout ça, apprenez à maîtriser le refactoring et le design émergent
brillant