Le code, sa complexité et ses performances

Une des choses les plus importantes de la revue de code, c’est de détecter les rapidement les problèmes de conception et d’architecture d’un code qui va être envoyé en production. Cette tâche est délicate, car elle fait appel à la subjectivité du ou des relecteurs. Il faut trouver le “juste milieu” afin d’éviter d’en faire trop ou pas assez. Souvent, le principal argument utilisé pour éviter de découpler du code est que le fait de rajouter une classe va complexifier le code, en plus de dégrader les performances de l’application.

Dans le choix de mise en place d’une architecture, il est important de prendre en compte un certain nombre d’aspects techniques, organisationnels et métier. Il y a néanmoins des principes de base qui devraient (à mon sens) être systématiquement appliqués et cela, peu importe le type de l’application développée. En respectant certaines règles élémentaires, on facilitera l’écriture d’un code simple, évolutif, maintenable et scalable.

Le premier principe fondamental est d’avoir une séparation entre l’aspect technique d’un code et son aspect business. Très schématiquement, il s’agit de séparer l’objectif métier du code des détails de son implémentation technique. Par exemple, dans le cadre d’un site d’e-commerce, un des besoins métier est de gérer le panier afin de pouvoir y ajouter, modifier, enlever des produits que l’on souhaite acheter ou non. L’aspect technique est de gérer la manière dont ces informations vont être “enregistrées” (en session, en base de données…). Il est donc important que le code sépare ces deux notions pour limiter les impacts d’une éventuelle modification.

C’est un bon début, mais cela ne suffit pas. Il faut également découper l’aspect technique en plusieurs responsabilités. Ici, il convient d’avoir des briques logicielles qui ne font qu’une seule chose, qui ne remplissent qu’un objectif (récupérer de la donnée, générer des affichages, produire des logs, faire des traitements métiers, etc.). Se retrouver avec du code qui mixe ces concepts est une erreur. En plus de lier des notions sans rapport entre elles, cela risque de rendre votre code difficilement testable.

Les règles qui ont été présentées jusqu’ici sont d’autant plus vraies, qu’elles peuvent s’appliquer à n’importe quel langage et pour n’importe quel type d’application. Si vous avez du code qui ne les respecte pas, vous avez certainement une forte dette technique.

J’entends souvent (même venant de développeurs expérimentés) que découper son code en plusieurs responsabilités n’apporte pas de valeur, complexifie le code et dégrade les performances de l’application.

Ajouter du code peut effectivement complexifier la compréhension d’un programme. Mais, ajouter du code structuré en classe et découpé en différentes méthodes (correctement nommées), vise bien au contraire à améliorer la compréhension de ce dernier. De plus, cela n’a que peu d’impact sur les performances d’exécution. En réalité, ce n’est pas le découpage du code qui nuit aux performances d’une application, mais la manière dont ce dernier est écrit.

Il faut bien se rendre compte qu’à code équivalent, même avec un découpage en plusieurs classes, les performances seront équivalentes (les langages modernes sont pour la plupart dotés de mécanismes d’optimisation et de mise en cache).