Inspiré par Ohloh, et devant la nécessité de commencer à évaluer la migration d’un grand ensemble de sites Drupal de Drupal 4.7 vers Drupal 5.x/6.x, j’ai entrepris de créer un outil d’analyse statique et de métriques de code conçu spécifiquement pour PHP et Drupal.
Le code est disponible dans le dépôt svn public de Bryght, à l’adresse de dépôt https://svn.bryght.com/dev/svn/scripts/metrics.
Le programme metrics.php est pour l’instant un script en ligne de commande, que l’on pointe vers un répertoire contenant le code à analyser :
% php metrics.php code_dir
Les rapports sont produits sur la sortie standard.
Historique
Ce code est parti du script sloccount.php écrit par Arto Bendiken. J’ai tenté d’enrichir le script en le rendant plus complet et plus précis, mais aussi plus souple et plus général. L’architecture se veut modulaire, pour permettre aux utilisateurs d’écrire facilement des outils d’analyse pour de nouveaux types de fichiers.
Deux types de fichiers sont actuellement pris en charge : générique et PHP.
L’analyse « générique » prend en charge le code de style C, avec des commentaires en ligne introduits par « // » et des blocs de commentaires délimités par « /* » et « */ ». On obtient ainsi des métriques approximatives pour les fichiers JavaScript et CSS.
L’analyseur PHP utilise le tokenizer de PHP et un analyseur syntaxique rudimentaire pour obtenir des informations supplémentaires sur le code PHP.
L’analyse est complètement séparée de la production des rapports : la phase d’analyse construit un tableau de métriques par fichier, chaque métrique pouvant elle-même être structurée.
Les rapports actuels comprennent des statistiques de base sur le nombre de lignes, le nombre de commentaires (en ligne et de style doc), le nombre de fonctions et le nombre de jetons (classés par catégorie, p. ex. contrôle, opérateur…), ainsi que la liste des variables et des constantes (et des lignes où elles sont utilisées), les fonctions et les lignes où elles sont définies, une estimation CoCoMo de base et la distribution de fréquence des jetons PHP.
Travaux futurs
C’est encore très sommaire. Maintenant que j’ai écrit une première version, je constate qu’il faut tout refaire.
Le code peut actuellement être étendu pour traiter différents types de fichiers, même si les détails de cette extensibilité doivent être rendus plus sensés. Mais en réalité, l’analyse et les rapports devraient être orientés objet pour tirer parti de l’héritage : il devrait y avoir un analyseur Drupal qui étend l’analyseur PHP, lequel étend à son tour l’analyseur générique.
Il y a beaucoup de place pour la créativité quant à l’empaquetage de l’outil, au traitement d’autres types de fichiers, à l’affichage des résultats et à la construction de modèles plus significatifs.
Un projet facile (du moins les premiers 80 %) serait d’écrire un tokenizer et analyseur syntaxique CSS.
Une piste que j’aimerais explorer : des modèles de coûts fondés sur les statistiques, dont les paramètres seraient calculés à partir de l’analyse des coûts connus de code réel.
Mesurer la complexité selon des facteurs comme les expressions booléennes et arithmétiques, la récursivité, la couverture de certaines parties de l’API (p. ex. la complexité des requêtes SQL) : autant d’extensions possibles.
Une autre piste est l’analyse propre à Drupal, qui permettrait d’examiner le nombre de hooks implémentés, la version de Drupal pour laquelle le code est écrit, et le nombre de fonctions du cœur, de modules contribués ou hors Drupal appelées par unité de code.
Un projet intéressant serait d’élaborer un modèle de coût pour la mise à niveau d’un site donné vers une version donnée de Drupal, en fonction des changements d’API et d’estimations de la quantité de code à modifier.
La sélection et la génération automatique de cas de test (ébauches de tests unitaires) pourraient aussi en être une application.
Vos commentaires et contributions sont les bienvenus!
Voir le fichier texte joint pour un exemple de sortie (simplifiée) de metrics.php exécuté sur l’extraction CVS du dépôt des contributions, étiquette DRUPAL-4-7, le 9 novembre 2007 :
- 2990 fichiers PHP
- 267 fichiers JavaScript
- 495 fichiers CSS
- 632 autres fichiers (« intéressants »)
pour un total de 4 384 fichiers analysés. 45 248 Ko de code dans les fichiers considérés, contenant 874 838 lignes de code et 23 790 définitions de fonctions. Coût total selon le modèle CoCoMo « organique » : 10 245 457,00 $ à 60 000 $ par année par développeur.