Eh bien, la mesure que j'utilise, ou que je pense utiliser, est la suivante:
Pour chaque exigence fonctionnelle indépendante, unique, d'une ligne, à prendre ou à laisser, prenez un instantané de la base de code avant de l'implémenter. Ensuite, implémentez-le, y compris la recherche et la correction de tous les bogues introduits dans le processus. Exécutez ensuite un diff
entre la base de code avant et après. L ' diff
affiche une liste de toutes les insertions, suppressions et modifications qui ont implémenté la modification. (Comme l'insertion de 10 lignes de code consécutives est un changement.) Combien de changements y avait-il? Plus ce nombre est petit, généralement, plus le code est maintenable.
J'appelle cela la redondance du code source, car c'est comme la redondance d'un code correcteur d'erreurs. Les informations étaient contenues dans 1 bloc, mais ont été codées comme N blocs, qui doivent tous être faits ensemble, pour être cohérents.
Je pense que c'est l'idée derrière DRY, mais c'est un peu plus général. La raison pour laquelle il est bon que ce nombre soit faible est que, s'il faut N changements pour implémenter une exigence typique, et en tant que programmeur faillible, vous n'en faites que N-1 ou N-2 correctement au début, vous avez mis en 1 ou 2 bugs. En plus de l'effort de programmation O (N), ces bogues doivent être découverts, localisés et réparés. C'est pourquoi le petit N est bon.
Maintenable ne signifie pas nécessairement lisible, pour un programmeur qui n'a pas appris comment fonctionne le code. L'optimisation de N peut nécessiter de faire certaines choses qui créent une courbe d'apprentissage pour les programmeurs.
Voici un exemple.
Une chose qui aide est si le programmeur essaie d'anticiper les changements futurs et laisse des instructions pratiques dans le commentaire du programme.
Je pense que lorsque N est suffisamment réduit (l'optimum est 1), le code source ressemble davantage à un langage spécifique au domaine (DSL). Le programme ne «résout» pas tant le problème qu'il «énonce» le problème, car idéalement chaque exigence est simplement reformulée comme un seul morceau de code.
Malheureusement, je ne vois pas beaucoup de gens apprendre à faire cela. Ils semblent plutôt penser que les noms mentaux devraient devenir des classes, et les verbes devenir des méthodes, et tout ce qu'ils ont à faire est de tourner la manivelle. Cela résulte en un code avec N de 30 ou plus, d'après mon expérience.