Comment définir la qualité du code ?

Question

Quelqu'un a-t-il une définition raisonnable de Qualité du code ? Je ne pense pas qu'il existe une bonne définition, et je vois beaucoup de mauvaises définitions. Il existe de nombreuses définitions de la correction, mais je m'attendrais à ce que la correction soit une donnée, et la qualité n'a pas de sens si le code est cassé.

Je soupçonne que la qualité est quelque chose comme :

correctness               AND spec-conformant AND
clever                    AND not-too-clever  AND
simple                    AND not-too-simple  AND
uses-sensible-algorithms  AND
does-not-reinvent-wheel   AND
uses-appropriate-language AND
lacks-bad-smells          AND
concise                   AND
clear                     AND
well-documented           AND
with-good-performance     AND
elegant                   AND not-baroque

mais c'est sans espoir. Quelqu'un a-t-il une meilleure définition ?

Answer 1

Je pense que la qualité du code est trop subjective pour être notée. La meilleure façon de la décrire est la suivante :

Le code est comme les pets. Il pue si ce n'est pas le vôtre.

Même si vous pensez qu'un morceau de code est génial, quelqu'un d'autre le regardera et pensera "Ce n'est pas très bon".

Les qualités que vous avez décrites ci-dessus sont exactement ce qui décrit un bon code, mais ce sont toutes des qualités subjectives. Il n'y a aucun moyen de le noter, donc chaque personne le verra différemment.

Tant que ce n'est pas horriblement mauvais, tout va bien, à mon avis. Il est utile que tous les développeurs d'un projet s'assoient et fassent une revue de code. Cette bande dessinée est la meilleure description que j'ai vue de ce que devrait être une revue de code, qu'elle soit bonne ou mauvaise :

Answer 2

Ma définition de la qualité du code est la suivante LTFCE basé sur la notion que le code est de la littérature. Au cours de sa durée de vie (maintenance, réutilisation, etc.), le code sera lu beaucoup plus de fois qu'il n'a été écrit. Ainsi, un bon code est ( dans l'ordre )...

1. L egible - Le code (le le code lui-même et non des commentaires) devrait clairement l'intention. Si le lecteur ne peut pas donner un sens au code, alors tous les autres efforts sont voués à la frustration, voire à l'échec pur et simple.

2. T estable - Le code devrait être organisé de manière à faciliter les tests unitaires. Cela supporte tous les efforts ultérieurs (refactoring pour modification, correction des défauts, révision due à un changement de spécifications, etc.)

3. F lexible - Dépendances, à la fois sur d'autres codes de la base de code et sur des implémentations arbitraires. des choix d'implémentation arbitraires, doivent être réduites au minimum. Codé en dur hypothèses sur la taille des données, les classes concrètes ou les structures de données, etc. rendent le code plus fragile et, par conséquent donc plus difficile à réutiliser ou à adapter.

4. C ompliant - Le code doit être conforme à ses exigences, fonctionnelles et autres. (Je ne Je ne dis pas que c'est "correct" car la discussion sur la question de savoir si les exigences elles-mêmes étaient les "bonnes" exigences concerne le processus processus ou l'environnement, et non sur le code).

5. E conomique - Le code doit faire un usage raisonnable des ressources système système : mémoire, processeur, etc. (Je ne dis pas cela comme "efficace" car car ce mot est trop souvent souvent mal utilisé, en le limitant à un seul aspect aspect, comme la vitesse. L'économie est simplement une question de retour sur investissement, et nécessite une réflexion sur tous les ressources investies et à toutes les mesures mesures du rendement).

L'intérêt d'insister pour que ces éléments soient considérés dans l'ordre est que chaque propriété soutient celles qui suivent. Par exemple, les défauts (non-respect des spécifications) dans un code lisible, testable et flexible peuvent probablement être corrigés avec un effort raisonnable. D'un autre côté, je pense que chaque programmeur a fait l'expérience d'un code micro-optimisé pour les performances au point d'être trop fragile pour une maintenance raisonnable.

Answer 3

Bon code vous vous sentez bien quand vous le lisez . En d'autres termes, la qualité du code est liée à quelque chose qui se passe derrière les yeux d'un programmeur, et non à une mesure externe. Elle est subjective car les attentes des différents programmeurs diffèrent en fonction de leur expérience et de la tradition dans laquelle ils ont été formés.

Je n'insisterais pas trop sur l'exactitude. Un bon code avec 5 bogues est bien meilleur qu'un code merdique qui passe tous les tests connus. Lequel voulez-vous maintenir ?

Les mesures individuelles que vous citez sont utiles principalement comme moyens testables pour améliorer et non pour l'évaluer . Par exemple,

• Si je simplifie ce code tout en le rendant 20 % plus rapide, je me sentirai beaucoup mieux.

L'un des avantages des revues de code est que vous pouvez commencer à développer des normes de groupe sur ce qui vous semble bon (et donc ce que vous voulez maintenir).

Answer 4

Vous pouvez vous contenter de dire "haute qualité" == "répond aux exigences".

Commencez ensuite à définir ce que sont les exigences : par ex. fonctionnel, bon marché, fiable, accessible, ...

Cela permettrait de lier la "qualité" aux exigences et au contexte, c'est-à-dire aux propriétés qui sont perçues, mesurées et importantes pour l'utilisateur. parties prenantes (ce qui peut inclure, mais ne se limite certainement pas aux programmeurs).

---

Notez que "bon marché", en tant que qualité, est en corrélation avec d'autres mesures telles que "ne réinvente pas la roue" (dans le PO), et, avec "maintenable" et avec "élégant" : Je pense que "peu coûteux" est une conséquence de la qualité de la conception, et est une qualité (mesurable) en soi.

De même, la "rapidité" est aussi une mesure de la qualité.

Certaines personnes pourraient dire que "rapide" et "bon marché" ne sont pas des mesures de la qualité des logiciels : par exemple http://en.wikipedia.org/wiki/Project_triangle#Example suggère qu'ils sont antithétiques à la qualité ... mais mon idée de "qualité" est informée par http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance Je considère donc la "qualité" comme plus centrale, comme quelque chose qui informe les gens sur leur perception de l'environnement. chaque l'aspect de la chose.

Answer 5

Un code de haute qualité :

• Facile à comprendre pour les autres programmeurs
• Facilité de maintenance pour les autres programmeurs
• Facile à utiliser pour les utilisateurs cibles
• Fonctionne bien