La complexité cyclomatique permet de déterminer si votre code doit être refactorisé. Le code est analysé et un nombre de complexité est déterminé. La complexité est déterminée par la création de branches (si des instructions, etc.). La complexité peut également prendre en compte l'imbrication de boucles, etc., ainsi que d'autres facteurs en fonction de l'algorithme utilisé.
Le nombre est utile au niveau de la méthode. Aux niveaux supérieurs, ce n'est qu'un chiffre.
Un nombre de 17 754 indique la complexité au niveau du projet (code total), ce qui n'a pas beaucoup de sens.
Une analyse approfondie de la complexité de la classe et du niveau de la méthode déterminera les zones du code qui doivent être restructurées en méthodes plus petites ou redéfinies pour en éliminer la complexité.
Considérons une CASE
déclaration avec 50 cas dans une méthode. Peut-être que chaque état a une logique métier différente. Cela générera une complexité cyclomatique de 50. Il y a 50 points de décision. Il peut être nécessaire de repenser l'instruction CASE à l'aide d'un modèle d'usine pour supprimer la logique de branchement. Parfois, vous pouvez refactoriser (diviser la méthode en parties plus petites) et dans certains cas, seule une refonte réduira la complexité.
En général, pour la complexité du niveau de la méthode:
- <10 Facile à entretenir
- 11-20 Plus difficile à maintenir
- 21+ candidats pour refactoring / refonte
Considérez également que des complexités plus élevées rendent le code plus difficile à tester.
La complexité la plus élevée que j'ai vue sur une seule méthode était de 560. Il s'agissait d'environ 2000 lignes d'instructions if dans une méthode. Essentiellement intangible, indestructible, plein de bugs potentiels. Imaginez tous les cas de tests unitaires nécessaires à cette logique de branchement! Pas bon.
Essayez de garder toutes les méthodes moins de 20 ans et réalisez qu'il y a un coût à refactoriser n'importe quelle méthode pour la rendre moins complexe.