Quelle est la taille idéale d'une classe ?

L'évaluation de la maintenabilité des programmes est un enjeu majeur pour l'industrie logicielle. En effet, selon Canfora et Cimitile (2001), la maintenance représente entre 60% et 80% du coût total d'un programme, en incluant les évolutions et les corrections d'anomalies. Toujours selon ces auteurs, le facteur le plus déterminant est la compréhension du programme déjà écrit.

De nos jours, l'approche classique d'évaluation de la maintenabilité repose sur l'apprentissage automatique. Cela consiste d'abord à compter un certain nombre d'éléments du code source qui nous intéressent, les fameuses métriques, puis à entrainer un algorithme pour prédire la maintenabilité à partir de ces métriques.

Afin d'entraîner convenablement les algorithmes, il est nécessaire d'avoir une valeur de référence fiable, comme le jeu de données de Schnappinger et al (2020) basé sur des évaluations par des experts. Pour des raisons pratiques, il est plus simple pour les experts d'évaluer la maintenabilité au niveau des classes. La figure ci-dessous présente ce jeu de données. Elle représente la maintenabilité en fonction de la taille des classes, exprimée ici en nombre de lignes (LOC - Lines of Code), unité universelle et absolument jamais contestée de la productivité. La meilleure maintenabilité est représentée par une valeur de zéro et la plus mauvaise est représentée par une valeur de trois. Les différents projets Java d’où sont issus les points du jeu de données sont représentés.

Inutile d'investir 3 ans de recherche pour conclure à partir de cette figure que la taille d'une classe est le principal indicateur de sa maintenabilité. Lors de son doctorat, votre serviteur, que personne n'avait mis au courant, s'est intéressé à cette problématique. Il se trouve qu'un prédicteur basé uniquement sur le nombre de lignes de code obtient de meilleurs résultats que des experts humains évaluant la maintenabilité (Bertrand 2024, ch. 7.3). La logique est simple, selon le nombre de lignes de code de la classe Java (LOC) :

1. Si LOC < 80 ⇒ Parfaitement maintenable
2. Si LOC < 275 ⇒ Maintenable
3. Si LOC < 500 ⇒ Non maintenable
4. Sinon ⇒ Pas du tout maintenable

Ce prédicteur vous permettra d'évaluer la maintenabilité de vos classes avec une grande fiabilité. Il n'est donc pas nécessaire de solliciter la précieuse expertise de vos architectes, probablement occupés à relire les écrits d'Ada Lovelace ou préparer leur dernière conférence sur Quarkus.

Un tel résultat peut paraître absurde ! En effet, cela voudrait dire que découper nos classes Java en plus petites classes suffirait à en garantir la maintenabilité. De ce point de vue, le couplage des classes entre elles ou la complexité algorithmique interne d'une classe n'a que peu d'importance.

Toutefois, si on se réfère au célèbre Clean Code de Robert C. Martin, on se rendra rapidement compte que de nombreuses règles concernent directement ou indirectement la taille :

• Les fonctions doivent être petites ;
• Le nombre idéal d'arguments d'une fonction est zéro ;
• Une fonction ne doit faire qu'une seule chose ;
• Les classes doivent être petites ;
• Les classes doivent avoir un petit nombre de variables d'instance ;
• Une classe ne doit avoir qu'une seule responsabilité.

Ainsi, il est logique que la taille soit un bon prédicteur de la maintenabilité logicielle. En effet, lorsque le développeur rencontre une difficulté, technique ou fonctionnelle, il peut s'égarer dans le code et ajouter un peu trop de fonctionnalités à une classe ou adopter une solution structurellement sous-optimale. Les développeurs n'écrivent pas du code pour rien ou pour le plaisir, une trop grande classe est le symptôme d'un problème sous-jacent qui impacte la maintenabilité.

Ainsi, au vu des résultats expérimentaux, il est possible de considérer la taille idéale d'une classe Java, c'est à dire d'une classe parfaitement maintenable qui implémente néanmoins un nombre optimal de fonctionnalités. Soit ω cette taille idéale pour une classe Java :

Évidemment, ceci dépend du langage de programmation. Par exemple, il est de notoriété publique que Python est beaucoup plus concis que la plupart de ses concurrents. Ainsi, Raemaekers (2015) compare les langages à l'aide de leurs taux de compression, c'est-à-dire la capacité à exprimer une intention complexe, et du nombre d'instructions par points de fonction, une mesure de la verbosité brute. Raemaekers (ch. 7.5.1) présente la table ci-dessous, traduite pour votre plus grand confort.

Il est particulièrement intéressant de considérer Python, langage de LA DATA et échafaud de nos intelligences artificielles. Au vu de son adoption météorique par les développeurs, il fait peu de doute que Python est le langage ultime. On peut alors se poser la question de la valeur ω pour ce dernier.

Le coefficient δ est un coefficient de conversion de verbosité fonctionnelle de Java vers Python. Il est possible de le formuler comme l'isobarycentre des ratios des taux de compression ξ et des ratios du nombre d'instructions par point de fonction ψ.

En se basant sur les valeurs empiriques du tableau, le coefficient δ peut être évalué.

En réinjectant le coefficient de conversion de verbosité fonctionnelle dans notre équation de conversion, nous obtenons la réponse à la question ultime :
Quelle est la taille idéale d'une classe ?

Post mortem : Toute ressemblance avec une démonstration mathématique complexe pour justifier une intuition que tout le monde avait déjà serait purement fortuite. Bien que tout soit véridique dans cet article, il souffre évidemment d'un biais de confirmation très prononcé… et cela a demandé beaucoup de travail !