Votre code IA est-il de la pure DAUBE ? (Voici comment corriger ça)
BBetter Stack
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Aujourd'hui, je veux parler du CRAP. Et non, il ne s'agit pas de ce genre de CRAP. Je parle de
00:00:05l'abréviation qui signifie Change Risk Anti-Patterns Index. Et c'est conçu pour trouver
00:00:12les fonctions risquées dans votre code, qui sont très complexes, mais mal testées. Ce n'est pas
00:00:18un concept particulièrement nouveau, mais qui a attiré mon attention récemment, grâce à un paquet publié par
00:00:24Alexander Prokhoranko appelé Cargo CRAP, qui identifie ces fonctions clés dans le code Rust.
00:00:31L'idée originale de la métrique CRAP vient d'Alberto Savoia et Bob Evans, qui ont inventé la
00:00:37métrique en 2007 alors qu'ils expérimentaient avec des outils de test automatisés pour développeurs. Mais Alexander
00:00:44a récemment relancé l'attention sur cette métrique oubliée en écrivant cet article perspicace
00:00:49à ce sujet et sur la façon dont, de nos jours, alors que presque tout le code est écrit par des agents IA, il est plus important que jamais
00:00:55de scanner votre base de code pour ces problèmes cachés. C'est un concept très cool et nous allons l'explorer
00:01:01plus en détail dans la vidéo d'aujourd'hui. Alors, plongeons dedans. Pour comprendre pourquoi cela compte, examinons
00:01:11cette fonction sur mon écran. Elle gère une transformation de données en plusieurs étapes avec des instructions “match”
00:01:16profondément imbriquées, quelques boucles et de nombreux chemins de gestion d'erreurs. Sa complexité cyclomatique est donc assez élevée, environ 15.
00:01:24Maintenant, si vous n'êtes pas familier avec le terme complexité cyclomatique, c'est fondamentalement une façon élégante de mesurer
00:01:30combien de chemins différents une donnée peut emprunter dans votre code. Chaque fois que vous écrivez une instruction “if”
00:01:36ou un “match” ou une boucle “while” ou un bloc “catch”, vous créez une bifurcation, et plus vous avez de bifurcations,
00:01:43plus le score de complexité augmente. Et plus il devient difficile pour un cerveau humain de cartographier chaque résultat possible
00:01:51dans une fonction. C'est pourquoi, dans la mesure du possible, nous essayons de diviser les fonctions en petites tâches.
00:01:57Et pour cette fonction sur mon écran, une complexité de 15 signifie qu'il y a 15 chemins distincts
00:02:04que cette logique peut exécuter du début à la fin. Maintenant, si cette fonction est entièrement couverte par des tests unitaires,
00:02:09son score CRAP reste à 15. C'est complexe, mais c'est sûr car nous validons son comportement.
00:02:16Et c'est ce à quoi nous devrions nous attendre lorsque nous exécutons l'outil d'Alexander, CargoCrap. Et ici, nous voyons que le score est de 13,
00:02:23pas 15. C'est probablement parce que la bibliothèque n'a pas pris en compte les gestionnaires d'erreurs.
00:02:27Mais bref, 15 et 13 sont assez proches. Donc, en gros, cet outil fait ce que nous attendons.
00:02:33Mais regardons ce qui se passe si quelqu'un supprime ces tests ou si un agent IA génère cette fonction
00:02:39à partir de zéro et oublie complètement d'écrire des tests. Dans cet exemple, je vais juste mettre mes tests en commentaire.
00:02:45Et si nous réexécutons CargoCrap, le score dépasse soudainement 100.
00:02:51Il utilise donc une formule simple pour calculer le risque en équilibrant la complexité cyclomatique,
00:02:57le nombre de chemins d'exécution linéaires dans votre code par rapport à la couverture des tests.
00:03:03Donc, si nous regardons cette fonction, C est la complexité cyclomatique de la fonction et COV est la couverture des tests
00:03:10exprimée sous forme de fraction entre zéro et un. Et le calcul pénalise lourdement le code complexe qui manque de tests.
00:03:17Ainsi, si votre couverture est de cent pour cent, tout le premier chemin de l'équation tombe à zéro
00:03:23et votre score CRAP égale simplement votre complexité cyclomatique.
00:03:26Mais si votre couverture chute, l'exposant cubique sur le côté gauche fait monter en flèche le score de risque.
00:03:33Et une fonction avec une complexité de 10 et une couverture de zéro donne un score CRAP de 110.
00:03:39Et c'est une bonne chose, car si vous voulez une base de code où, par exemple,
00:03:43aucune fonction ne dépasse une complexité cyclomatique de cinq, alors c'est votre métrique de base à surveiller.
00:03:49Et si une fonction dépasse cinq, vous savez que c'est une zone à laquelle faire attention.
00:03:55Normalement, vous pourriez autoriser une complexité plus élevée. CargoCrap a une valeur par défaut fixée à 30.
00:04:00Mais je dis simplement que vous pouvez définir cette métrique vous-même comme vous le souhaitez.
00:04:05C'est donc essentiellement une bonne métrique intermédiaire à surveiller.
00:04:09Et cela devient critique à l'ère du code généré par IA.
00:04:13Parce que les agents IA sont incroyablement doués pour produire ces blocs de code syntaxiquement corrects
00:04:20hautement complexes qui gèrent des cas limites auxquels vous n'aviez même pas pensé, mais ils sont notoirement mauvais pour écrire
00:04:25des tests d'intégration significatifs et robustes à moins d'y être explicitement forcés.
00:04:30Des outils comme CargoCrap sont donc destinés à être exécutés en deuxième vérification après tous les tests unitaires
00:04:37pour évaluer la qualité globale du code.
00:04:39Cela agit donc essentiellement comme une carte thermique pour votre dette technique, vous pointant directement vers le code
00:04:44qui est le plus susceptible de casser lors d'une refactorisation.
00:04:47Et c'est aussi particulièrement utile si vous voulez garder votre base de code bien structurée
00:04:52au cas où vous devriez intégrer un nouvel ingénieur dans votre équipe.
00:04:56Et nous savons, d'après des comptes rendus anecdotiques, à quel point les bases de code peuvent devenir folles avec tout ce
00:05:02code généré par IA aujourd'hui si nous n'y prêtons pas attention.
00:05:06Et parfois, ces agents IA ont aussi tendance à dupliquer la même fonction dans plusieurs fichiers.
00:05:13Je pense donc que des outils comme ceux-ci, et surtout des méthodologies comme celles-ci, sont importants à connaître
00:05:19et à ne pas oublier dans notre paysage de codage moderne pour maintenir une haute qualité de code.
00:05:24Les mêmes auteurs qui ont proposé cette méthodologie ont également publié un outil de métrique CRAP pour Java.
00:05:30Et honnêtement, jusqu'à ma lecture récente de l'article d'Alexander, je n'étais même pas au courant de cette métrique.
00:05:34Je suis donc reconnaissant que son outil m'ait fait remarquer cette pratique d'ingénierie oubliée depuis longtemps.
00:05:40Et je suis sûr que d'autres langages de programmation bénéficieraient également d'un tel outil.
00:05:44Donc, si vous cherchez un projet amusant à construire pendant votre temps libre,
00:05:48allez lire l'article original d'Alberto Savoia et construisez-en un pour un autre langage de programmation
00:05:53car cela pourrait être un utilitaire très utile pour beaucoup de développeurs.
00:05:57Voilà, les amis.
00:05:58C'est tout pour le CRAP.
00:06:01Ça sonnait drôle.
00:06:02Bref, quelles sont les autres pratiques ou métriques d'ingénierie oubliées que vous connaissez
00:06:08et auxquelles nous devrions prêter plus d'attention dans cette nouvelle ère du codage agentique ?
00:06:13Faites-le-nous savoir dans la section des commentaires ci-dessous.
00:06:15Et les amis, si vous aimez ce genre de breakdowns techniques,
00:06:18faites-le-moi savoir en fracassant ce bouton “j'aime” sous la vidéo.
00:06:21Et n'oubliez pas non plus de vous abonner à notre chaîne.
00:06:24C'était Andrus de BetterStack et je vous verrai dans les prochaines vidéos.
00:06:28On se voit dans les prochaines vidéos.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video