<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Sébastien Bertrand</title>
    <description>The latest articles on DEV Community by Sébastien Bertrand (@dhmoclex).</description>
    <link>https://dev.to/dhmoclex</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F1097191%2Ff03a670a-8c3b-488d-bed4-01db4d6e406f.jpeg</url>
      <title>DEV Community: Sébastien Bertrand</title>
      <link>https://dev.to/dhmoclex</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/dhmoclex"/>
    <language>en</language>
    <item>
      <title>Quelle est la taille idéale d'une classe ?</title>
      <dc:creator>Sébastien Bertrand</dc:creator>
      <pubDate>Tue, 23 Dec 2025 09:00:00 +0000</pubDate>
      <link>https://dev.to/onepoint/quelle-est-la-taille-ideale-dune-classe--2jhg</link>
      <guid>https://dev.to/onepoint/quelle-est-la-taille-ideale-dune-classe--2jhg</guid>
      <description>&lt;p&gt;L'évaluation de la maintenabilité des programmes est un enjeu majeur pour l'industrie logicielle. En effet, selon &lt;a href="https://doi.org/10.1142/9789812389718_0005" rel="noopener noreferrer"&gt;Canfora et Cimitile (2001)&lt;/a&gt;, 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.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &lt;a href="https://doi.org/10.1109/ICSME46990.2020.00035" rel="noopener noreferrer"&gt;Schnappinger et al (2020)&lt;/a&gt; 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), &lt;em&gt;unité universelle et absolument jamais contestée de la productivité&lt;/em&gt;. 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 &lt;em&gt;Java&lt;/em&gt; d’où sont issus les points du jeu de données sont représentés.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqcce9tdpl43x59d6hyue.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqcce9tdpl43x59d6hyue.png" alt="Figure qui présente la maintenabilité en fonction de la taille pour des classes _Java_, la figure montre clairement que plus les classes sont grandes, plus la maintenabilité est mauvaise." width="800" height="596"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;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é (&lt;a href="https://www.doi.org/10.13140/RG.2.2.12553.92009" rel="noopener noreferrer"&gt;Bertrand 2024, ch. 7.3&lt;/a&gt;). La logique est simple, selon le nombre de lignes de code de la classe &lt;em&gt;Java&lt;/em&gt; (LOC) :&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;1. Si LOC &amp;lt; 80 ⇒ Parfaitement maintenable
2. Si LOC &amp;lt; 275 ⇒ Maintenable
3. Si LOC &amp;lt; 500 ⇒ Non maintenable
4. Sinon ⇒ Pas du tout maintenable
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;Un tel résultat peut paraître absurde ! En effet, cela voudrait dire que découper nos classes &lt;em&gt;Java&lt;/em&gt; 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.&lt;/p&gt;

&lt;p&gt;Toutefois, si on se réfère au célèbre &lt;a href="https://dl.acm.org/doi/10.5555/1388398" rel="noopener noreferrer"&gt;Clean Code de Robert C. Martin&lt;/a&gt;, on se rendra rapidement compte que de nombreuses règles concernent directement ou indirectement la taille :&lt;/p&gt;

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

&lt;p&gt;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. &lt;em&gt;Les développeurs n'écrivent pas du code pour rien&lt;/em&gt; ou pour le plaisir, une trop grande classe est le symptôme d'un problème sous-jacent qui impacte la maintenabilité.&lt;/p&gt;

&lt;p&gt;Ainsi, au vu des résultats expérimentaux, il est possible de considérer la taille idéale d'une classe &lt;em&gt;Java&lt;/em&gt;, 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 &lt;em&gt;Java&lt;/em&gt; :&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fl04onngi711u6y12h85w.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fl04onngi711u6y12h85w.png" alt="Formule ω_java = 80" width="181" height="40"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Évidemment, ceci dépend du langage de programmation. Par exemple, il est de notoriété publique que &lt;em&gt;Python&lt;/em&gt; est beaucoup plus concis que la plupart de ses concurrents. Ainsi, &lt;a href="https://doi.org/10.4233/uuid:dbb70852-e06b-40f7-b872-60047f962dbc" rel="noopener noreferrer"&gt;Raemaekers (2015)&lt;/a&gt; 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.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F1643855tanckfrox03xo.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F1643855tanckfrox03xo.png" alt="Tableau qui présente le taux de compression et le nombre d'instructions par points de fonction pour différents langages. En particulier : le taux de compression est 9.03 pour Java et 4.88 pour Python, le nombre d'instructions par point de fonction est 41.8 pour Java, 21.3 pour Python." width="377" height="568"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Il est particulièrement intéressant de considérer &lt;em&gt;Python&lt;/em&gt;, langage de &lt;a href="https://www.cynicalturtle.net/kame/post/2020/12/24/Affordance-trompeuse-LA-DATA" rel="noopener noreferrer"&gt;LA DATA&lt;/a&gt; et échafaud de nos intelligences artificielles. Au vu de son adoption météorique par les développeurs, il fait peu de doute que &lt;em&gt;Python&lt;/em&gt; est le langage ultime. On peut alors se poser la question de la valeur ω pour ce dernier.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fr5efyjbkc9eyzg2dur4c.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fr5efyjbkc9eyzg2dur4c.png" alt="Formule ω_ultime = δ × ω_java" width="304" height="43"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Le coefficient δ est un coefficient de conversion de verbosité fonctionnelle de &lt;em&gt;Java&lt;/em&gt; vers &lt;em&gt;Python&lt;/em&gt;. 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 ψ.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fwvhz3rpentlsbl7tsb0e.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fwvhz3rpentlsbl7tsb0e.png" alt="Formule du coefficient δ qui correspond à la moyenne des ratios des taux de compression et des ratios du nombre d'instructions par point de fonction." width="401" height="100"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;En se basant sur les valeurs empiriques du tableau, le coefficient δ peut être évalué.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fjh8oga8i8wml1cywbg0m.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fjh8oga8i8wml1cywbg0m.png" alt="Application numérique : δ = 0.525" width="708" height="86"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;En réinjectant le coefficient de conversion de verbosité fonctionnelle dans notre équation de conversion, nous obtenons &lt;strong&gt;la réponse à la question ultime&lt;/strong&gt; : &lt;br&gt;&lt;em&gt;Quelle est la taille idéale d'une classe ?&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fpeg2xv6phd70tdmczzvi.png" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fpeg2xv6phd70tdmczzvi.png" alt="Formule finale ω_ultime = 42" width="206" height="34"&gt;&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;&lt;br&gt;
&lt;em&gt;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 !&lt;/em&gt;&lt;/p&gt;

</description>
      <category>adventoftech2025</category>
      <category>maintainability</category>
      <category>cleancode</category>
      <category>java</category>
    </item>
  </channel>
</rss>
