CEO : ne soyez plus otage du code

"Faites du code propre", "faites des tests", "pensez long terme" : les conseillers sont nombreux qui vous enjoignent à veiller à la qualité du code produit par l'entreprise que vous dirigez. Vous, vous vous dites que tous ces gens 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 casser aujourd'hui : les choses ne sont pas binaires, ce n'est pas tout ou rien, la qualité ou le quick and dirty. Autrement dit, la qualité est une gradation, un curseur. On peut faire "un peu" de qualité, on peut faire de la qualité de manière pragmatique.

Et donc c'est 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. Si vous ne le faites pas maintenant, vous pourrez toujours en rajouter ultérieurement, même si ça vous coûtera plus cher parce que le code n'aura pas été écrit pour être testé.

• 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, facilitant le test par la même occasion. Ce n'est pas rien, mais ce n'est pas insurmontable. Evidemment, si vous le faites dès le début, c'est mieux.

• La technologie ? Passer d'Express à Fastify ? 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.

S'il est en revanche une chose que vous ne devez pas négliger, que vous ne pouvez pas négliger au temps zéro de la création de votre produit, c'est la modularité. Au temps zéro, cela vous coûtera 1 : la réflexion se fait essentiellement sur papier. Par contre, si vous découvrez le sujet après des années de développement, cela vous coûtera 1000, 10000 ou 100000. L'ordre de grandeur est bien réel et s'explique par le fait que vous devrez supprimer des couplages indûs qui se seront installés à grande échelle dans le code. Vous devrez à peu près tout casser, et vous allez souffrir.

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 de refactorer ultérieurement sans tout casser. N'attendez pas que le code vous revienne en boomerang après quelques années : la qualité logicielle est un sujet business avant d'être un sujet technique.

En conclusion, disons-le : le débat vitesse vs. qualité est un faux débat, parce que les deux ne s'opposent pas. Si l'objectif est d'aller chercher des réponses ("mon produit se vendra-t-il ?" / "cette piste technique fonctionne-t-elle ?"), c'est un démonstrateur que vous devez faire, un POC. C'est rapide, c'est sale et c'est assumé. Si la réponse est favorable, vous repartez de zéro et posez des bases techniques saines à l'aide de personnes expérimentées pour aller en production le plus rapidement en contractant le minimum de dette technique (notion de Walking Skeleton).