Comment quantifier la qualité du code
Mon unité commerciale compte un grand nombre de développeurs (environ 100). Pour diverses raisons, les développeurs se concentrent presque uniquement sur la livraison plutôt que sur la qualité. Le code de mauvaise qualité a déjà commencé à nous faire du mal. Les bogues sont devenus difficiles à identifier. Le code est devenu fragile. Les tests unitaires sont assez déconnectés des exigences. Etc.
Je travaille étroitement avec la direction. À ce stade, je veux vouloir développer des stratégies pour récompenser un bon code. Je voudrais proposer des méthodes qui mesurent objectivement quelques paramètres énumérés ci-dessous. La raison pour laquelle je veux mesurer cela est de créer un environnement où les développeurs se sentent reconnus et appréciés lorsqu'ils écrivent du code de bonne qualité. (Je peux obtenir un support de gestion pour cela). À ce stade, la gestion est déconnectée de nos chiffres pour mesurer la qualité du code.
- Lisibilité du code
- Le degré de corrélation entre le test unitaire et les exigences (pas la couverture, les développeurs sont capables de couvrir le code avec des tests unitaires dénués de sens)
- La simplicité du design
Nous développons principalement en C # (applications mobiles, web et desktop)
Mise à jour 1: 14 novembre 2019
Sur la base des réponses brillantes, j'ai compris qu'il existe de nombreuses mesures pour mesurer la qualité et qu'elles doivent toutes être prises avec une pincée de sel. Ce fut un brillant aperç par Telastyn . "Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure". Cela m'a cloué.
À ce stade, je suis convaincu que nous devons prendre en compte l'élément humain dans la qualité du code (en particulier pour la lisibilité). Comment intéresser la direction à la mesure de la qualité du code (subjectivement et objectivement) est vraiment le défi auquel je suis confronté.
À ce stade, je veux vouloir développer des stratégies pour récompenser un bon code.
Vous ne pouvez pas. Loi de Goodhart entrera rapidement en jeu, et vos mesures objectives deviendront les choses sur lesquelles vos développeurs se concentrent, à l'exclusion de tout le reste.
Si votre gestion est déconnectée des éléments réels que vous produisez, ou ne fait pas confiance à vos chefs d'équipe qui ont un aperçu du code, alors les mesures ne sont pas va pas arranger ça. Vous avez un problème de gestion, pas un problème de code.
Les bases
Il existe de nombreuses façons de mesurer la qualité. Aucun d'eux n'est parfait: si vous commencez à penser en termes absolus, vous pouvez créer de nouveaux problèmes. Voici quelques mesures couramment utilisées:
- Complexité cyclomatique
- Couverture de test
- LOC par classe/méthode
- La duplication compte
Il existe également des mesures binaires qui peuvent être utilisées comme "portes" telles que la conformité aux normes ou la couverture minimale des tests.
Au lieu de vous débrouiller seul, je vous recommande d'essayer quelque chose comme SonarQube . Avec cela, vous obtenez toute une série de normes et de métriques que vous pouvez intégrer dans des tableaux de bord.
Je recommanderais de passer votre code à travers et de faire une analyse des résultats et de les partager avec votre direction. Ensuite, vous pouvez envisager de modifier certaines règles et de les utiliser pour rompre les versions; en supposant que vous disposez d'un serveur de génération et d'un processus géré pour la livraison. Cette partie nécessitera toutefois l'adhésion de la direction.
Appellation
Selon vos idées sur la dénomination, cela pourrait ne pas être possible. Je ne suis pas sûr qu'il existe un moyen de déterminer par programme si une variable est nommée correctement. Je peux penser à des choses
- longueur des noms (trop longue, trop courte)
- chiffres dans les noms (mauvais signe)
- ils devraient être des mots du dictionnaire
Mais en fin de compte, vous avez probablement besoin d'une équipe d'examen pour vous assurer que les noms sont significatifs. Quelqu'un dans l'équipe est-il d'accord avec vos préoccupations?
Essai
Cela peut être un peu controversé, mais je dirais que les tests unitaires n'ont pas besoin d'être connectés aux exigences. Le but des tests unitaires n'est pas de s'assurer que le code fait ce qu'il est censé faire. Le point est de vérifier que le code fait ce que vous vouliez qu'il fasse. Par exemple, votre test pour une fonction somme doit vous assurer qu'elle calcule correctement les sommes. Il n'est pas pertinent dans le test unitaire de savoir si l'exigence est de calculer une somme. C'est une distinction subtile mais cela fait vraiment une grande différence dans la façon dont vous écrivez les tests unitaires.
Le test des exigences doit avoir lieu dans une couche différente. Si vous utilisez des tests unitaires pour cela, vous devez mettre en place des suites de tests fonctionnels et de régression au niveau du composant ou de l'application.
Le défi des tests unitaires, au-delà de la couverture, est de savoir s'ils sont significatifs. Je pense que l'utilisation de la couverture de branche est une amélioration par rapport à la couverture de ligne, mais si un test peut simplement exécuter un chemin et ne rien vérifier.
Une idée qui me vient à l'esprit est que vous pourriez utiliser des outils de test de simulation ou de fuzz ici. Faites les tests unitaires et exécutez-les contre de mauvaises définitions de méthode. De bons tests devraient échouer dans ce scénario.
Visibilité
- Il est important que toute la base de code soit partagée et visible par l'équipe.
- Promouvoir l'examen par les pairs.
- Promouvoir la programmation par paires.
- Utilisez un analyseur de code statique, ces outils sont configurables et sont livrés avec un ensemble de règles prédéfinies qui peuvent être modifiées.
- Intégrez le SCA au flux de travail d'intégration continue et publiez des rapports de sémaphores automatiques visibles par tous.
- Bien que la qualité du code ne soit pas 100% mesurable, avoir des rapports visibles mesurant la longueur des classes et des méthodes, la complexité cyclomatique, la cohésion et toute une pléthore de paramètres, ainsi que les résultats des tests unitaires, puis en le transformant en une lumière verte, jaune ou rouge , donnera aux programmeurs une idée de si oui ou non leur code est propre et résume la qualité globale de la base de code et non l'inverse.
Mais pour moi, le mot magique est visibilité. Les gens en général ont tendance à mieux se comporter lorsqu'ils sont observés et les programmeurs ne font pas exception. Le code devrait être quelque chose dont on peut être fier, quelque chose dont on puisse parler au-dessus de la fontaine à eau. Parlez du code, respirez le code et pensez au code.
Vous dites également que le test unitaire ne vérifie pas que les exigences sont remplies, même avec une couverture à 100%. Je ne suis pas sûr de cela, les tests d'exigences ou d'histoires sont une question de tests d'acceptation ou de tests d'intégration, à tel point que vous ne pouvez pas nécessairement déduire les noms et la quantité de méthodes écrites pour satisfaire une certaine fonctionnalité. Certains tests unitaires peuvent cependant tester si une fonction, compte tenu de certaines entrées, renvoie le résultat attendu, et cela peut être effectué par rapport à une liste entière de milliers de valeurs précalculées. Le code qui ne peut pas le passer est cassé. Je pense que cela impose effectivement le respect des exigences. Il existe cependant d'autres exigences, qui sont la question des tests d'intégration, des tests de résistance et des tests d'acceptation.
BLUF: Utilisez tous les outils que vous pouvez pour mesurer et améliorer la qualité, mais comprenez leurs limites. Dans vos scénarios d'exemple, il semble que vous ayez besoin de certaines normes pour les évaluations par les pairs.
La qualité est par définition un concept flou:
La norme de quelque chose par rapport à d'autres choses du même genre; le degré d'excellence de quelque chose. (définition Google)
Alors qu'en informatique, nous fournissons tout le temps des chiffres quantitatifs à des concepts qualitatifs (scores de pertinence, probabilité de correspondance, etc.) ces scores sont rarement sous une forme qui peut être comparée les uns aux autres en dehors de l'ensemble particulier de données sur lequel elle a été exécutée. .
La qualité du code est un sujet très complexe, et ignorer le facteur - humain qui sépare le code qui suit aveuglément les "meilleures pratiques" et le code qui est vraiment de haute qualité revient à ignorer ce que vous voulez vraiment. Il existe différents outils pour améliorer la qualité et la cohérence, mais aucun d'eux ne peut dire avec autorité si le code est de qualité ou non.
Par exemple:
- Complexité cyclomatique: est une mesure des branches de code qui peuvent se produire, elle est plus utile au niveau de la fonction ou de la méthode. Plus il y a de branches et de boucles, plus il est difficile de suivre la logique dans cette fonction.
- Indice de maintenabilité: ( math ) est un score composite de la complexité cyclomatique, des lignes de code source et quelque chose appelé volume Halstead. Probablement l'une des meilleures mesures, mais elle ne peut pas couvrir la lisibilité ou la compréhension du code. Traitez la valeur comme un pourcentage.
- Outils Lint ou Static Analysis (comme SonarQube): fournissent un certain nombre de "meilleures pratiques" codifiées en règles. Le code qui suit ces règles est généralement plus facile à suivre et à maintenir que le code qui ne le fait pas. En règle générale, les règles doivent être personnalisées en fonction de votre produit, mais si tout le monde formate au moins le même code, cela améliore la lisibilité.
- Tests unitaires et commerciaux: aide à mesurer si le code est adapté à un usage particulier. Le présupposé ici est que les tests sont eux-mêmes écrits d'une manière qui échoue réellement si les conditions le justifient. ( Je ne peux pas vous dire combien de fois j'ai découvert qu'un test unitaire était simplement destiné à démarrer le débogueur et n'avait aucune assertion)
- BDD (Behavior Driven Development): crée des spécifications qui peuvent être instrumentées pour garantir que le code satisfait à ces exigences. Généralement utilisé à partir de l'interface utilisateur elle-même.
Bien que ces outils puissent aider vous améliorez différents aspects de votre code, il y a un certain nombre de choses qu'ils ne peuvent tout simplement pas évaluer. Ces choses ont également un impact direct sur la qualité du code:
- Pertinence des noms utilisés dans le code (c.-à-d. Méthode, variable, noms de classe)
- Évaluation de la cohérence conceptuelle (c.-à-d. Directeur à responsabilité unique, etc.)
- Adéquation des tests de correction
- Aptitude des algorithmes à résoudre les problèmes
- Cohérence conceptuelle
Je suis sceptique quant à la capacité de mesurer quantitativement la qualité; cependant, les tentatives pour ce faire nous ont fourni de bons outils pour mesurer les aspects de la qualité. C'est pourquoi nous avons besoin d'un humain pour regarder le code et poser des questions.
Je recommande d'utiliser des scores de qualité comme un mètre. Les compteurs ne vous indiquent que si vous respectez les normes de fonctionnement, et en regardant leurs valeurs au fil du temps, vous pouvez voir les tendances. Lorsqu'elles sont en dehors des normes, vous savez qu'il y a quelque chose à étudier. De plus, si la tendance est à un état défavorable, vous pouvez prendre des mesures correctives avant que le code ne va trop loin de cette façon.
Tout cela me semble inutile.
Pour diverses raisons, les développeurs se concentrent presque uniquement sur la livraison plutôt que sur la qualité
C'est donc votre problème mais vous préférez vous concentrer sur de nouvelles règles?
Les développeurs ne se soucient pas assez d'écrire du code maintenable ou ils sentent qu'ils n'ont pas le temps de terminer quoi que ce soit au-delà du point où les choses fonctionnent, dans le scénario le plus probable, pour le moment. Dans le premier cas, rien ne va aider. Dans le second cas, votre macro-processus est à blâmer et aucun micro-processus ne va le réparer.
Tout se résume à deux choses:
- des développeurs capables, attentionnés et assertifs
- attentes raisonnables au niveau de la direction
Si vous en avez, le reste suivra naturellement. Sinon, vous portez un toast de toute façon.
Je travaille en étroite collaboration avec la direction
Bien, vous pouvez donc vous assurer qu'aucune tâche ad hoc n'est engagée et que suffisamment de temps est attribué aux nouvelles fonctionnalités.