Graisse de classe | Pourquoi devrait-il être mesuré

Quelle est la taille de votre classe ? – Quelle est la taille trop grande? Pour quiconque écrit le code, il y a eu cette préoccupation – quelle devrait être la taille idéale de mon code dans une classe/méthode/fonction. Cela diffère de chaque développeur. Dans son livre Code Complete, Steve McConnell indique que si un élément est composé de plus de 30 sous-éléments, il est fort probable qu’il y ait un problème sérieux :

a) Les méthodes ne doivent pas comporter plus de 30 lignes de code en moyenne (sans compter les interlignes et les commentaires).

b) Une classe doit contenir en moyenne moins de 30 méthodes, ce qui donne jusqu’à 900 lignes de code.

c) Un package ne doit pas contenir plus de 30 classes, comprenant ainsi jusqu’à 27 000 lignes de code.

Des études montrent que le nombre de lignes de code est la base sur laquelle reposent la qualité et la complexité du logiciel que vous construisez. La valeur réelle d’une directive telle que la règle de 30 réside dans le fait que vous examinez le code et identifiez les risques et les coûts. Trop de lignes de code seront difficiles à compiler et à tester. Cependant, il n’y a pas de métrique idéale qui mesure le gras de la classe. Ce n’est pas seulement basé sur “l’opinion”, c’est basé sur le résultat de décennies de pratique. Les revues de code permettent d’identifier et de rectifier les problèmes dans la base de code. Les examens informels peuvent trouver 20 %-30% défauts de code. Des études chez IBM, HP, Microsoft et d’autres endroits montrent qu’il est plusieurs fois moins cher de trouver des bogues dans les revues de code que par des tests. Et les preuves de l’efficacité des revues de code ne cessent d’affluer. Horus, une plateforme de gestion de l’ingénierie, permet de passer en revue les lignes de code en cours d’écriture et ce qu’elles signifient pour les développeurs qui les écrivent, ainsi que les risques et les coûts qui y sont associés pour les cadres moyens et supérieurs, indépendamment du domaine, du niveau de maturité de l’organisation ou de la phase du cycle de vie au cours de laquelle elles ont été appliquées.
Pour en savoir plus sur Horus, consultez l’article précédent. Lisez aussi Complexité cyclomatique