Tout se rattrape, sauf la modularité

• Modularité
• CEO
• Best of

« Faites du code propre », « faites des tests », « pensez long terme », « qualité, qualité, qualité ! » Ils n’ont que ce mot à la bouche. Facile à dire… Vous, vous vous dites que tous ces consultants sont bien gentils, mais qu’ils n’ont jamais géré une entreprise et que ce sont d’horribles perfectionnistes. Trop, c’est trop, ça va bien et vous ne faites rien.

C’est humain, mais c’est précisément cette idée que j’aimerais remettre en question avec vous : les choses ne sont pas binaires, la qualité ou le quick and dirty. La qualité est un continuum, un curseur qu’il ne tient qu’à vous de positionner, avec la bonne information.

Dit autrement, oui, on peut faire un peu de qualité, on peut faire de la qualité de manière pragmatique. Tout cela est affaire de priorités.

La qualité logicielle, une question de priorités

Balayons rapidement le paysage : plutôt que de faire une dissertation pour définir ce qu’est la qualité (c’est une vraie question, mais ce n’est pas l’objet ici), abordons-la par l’angle des pratiques :

• Le test ? Si vous en êtes au stade du POC (Proof of Concept), il n’en est pas question ; si vous commencez à construire des choses durables, ce serait bien d’en avoir. Mais, bon, s’il faut vraiment arbitrer, vous pourrez toujours en rajouter plus tard (même si cela vous coûtera plus cher parce que le code n’aura pas été pensé pour être testé).

• La technologie ? Vos Devs veulent passer d’Angular à React ? C’est peut-être le sujet le plus visible, et paradoxalement le moins important. Si l’architecture est déjà en place et que vous disposez de tests, ces changements se font assez bien. Encore une fois, ce n’est jamais facile ni sans risque, mais c’est une opération courante.

• Et même… l’architecture ? Évidemment qu’elle est importante, mais à petite échelle vous pourrez la retravailler assez facilement. Vous pourrez par exemple refactorer votre code pour faire émerger une architecture hexagonale, et faciliter le test par la même occasion. Ce n’est pas rien, mais c’est loin d’être insurmontable.

Ce qui est insurmontable, en revanche, c’est de devoir casser l’architecture à grande échelle, c’est-à-dire la modularité. De sorte que, par contraste, toutes les considérations précédemment évoquées ne sont pas prioritaires.

Votre priorité absolue : la modularité

S’il est donc une chose que vous ne devez pas négliger, que vous ne pouvez pas négliger, c’est la modularité de votre produit. Pour bien le comprendre, il faut considérer que l’absence de modularité se traduit par des couplages, tous évitables, qui se sont installés à grande échelle. Vous refaites l’électricité et ça finit en problème de plomberie. Tout dépend de tout, il n’est plus possible de modifier quoi que ce soit sans casser autre chose. Le symptôme immédiat, ce sont des régressions en production et des délais qui explosent.

Par chance, travailler la modularité au temps zéro vous coûtera 10 à 20K€, parce que la réflexion se fait sur papier et qu’aux premières heures de vie d’un produit, il n’y a, par définition, pas d’existant à refactorer. Par contre, si vous découvrez le sujet après des années de développement, cela vous coûtera 10 à 100 fois plus, parfois plusieurs millions d’euros. L’ordre de grandeur est bien réel et s’explique par le fait que vous devrez détricoter le plat de spaghettis précédemment évoqué, ce qui, en pratique, conduit bien des organisations à repartir de la page blanche. On sait faire mieux, mais vous souffrirez quand-même.

Donc si vous ne devez retenir qu’une chose, c’est qu’une bonne modularité vous permet de supporter une piètre qualité logicielle localement et d’améliorer les choses ultérieurement sans tout casser. Un module peut accumuler bien des défauts : absence d’architecture, technologie obsolète, code médiocre, dette abyssale, pas l’ombre d’un test… Mais une bonne modularité en limite les conséquences au module lui-même, c’est le plus important. Le module d’à côté peut très bien être un petit bijou de développement et n’être nullement pollué par le premier, grâce à une modularité bien travaillée.

Une question de discipline

Pour être précis, la modularité ne se travaille pas une fois pour toutes. On établit une première carte fonctionnelle, qui évoluera par la suite au fur et à mesure que l’on va plus en détail sur chaque sujet, au fur et à mesure que l’application se construit.

Le livrable de la mission (l’output) pose des bases importantes, des premières frontières qui ne seront pas remises en question, mais au-delà, ce sont surtout les raisonnements qui comptent (l’outcome), car ce sont eux qui vous permettront de poursuivre sur de bons rails et en toute autonomie. 2 idées sont particulièrement importantes, et contre-intuitives :

• Le modèle universel n’existe pas : si je vous demande de « modéliser une table », la seule réponse qui vaille est « pour quoi faire ? » (une table de chirurgie ? une table à manger ? une table de poker?).

• Et son corollaire : découper par entité ne fonctionne pas. Il n’y aura donc jamais, au grand jamais, de module « table ». La fausse bonne idée !

Conclusion

Travailler la modularité est un effort très ciblé grâce auquel votre entreprise sera parée pour une croissance exponentielle d’ici quelques années. Vos modules ne sont pas aussi beaux que vous le voudriez ? Soit. Si déjà ils sont correctement définis, c’est beaucoup. C’est 90% du travail et un avantage incommensurable sur le long terme. Une bonne modularité est ce qui permet à vos équipes d’avancer en parallèle sans se marcher sur les pieds.