#252 Metrics Metrics Metrics

La métrique est un très bon moyen de faire de la revue de code et de trouver les parties de ce dernier qui peuvent être améliorées. Un des meilleurs outils de métrique pour Ruby est metric_fu, que nous avons déjà vu dans l'épisode 166 [regarder, lire]. Le seul souci est qu'il peut être difficile à mettre en place en raison de son grand nombre de dépendances, en particulier lorsqu'il est utilisé avec Rails 3. Une bonne alternative était le projet Caliper qui permettait de prendre n'importe quel dépôt Github et d'en obtenir la métrique. Ce projet a malheureusement fermé.

Nous en revenons donc à lancer la métrique sur notre machine locale. Il existe maintenant une gem, appelée Metrical, qui facilite grandement les choses. Metrical utilise metric_fu en arrière plan mais fournit une commande qui permet d'en faciliter l'usage.

La démonstration de Metrical sera effectuée sur le code source du site Railscasts. Tout d'abord, nous devons installer la gem Metrical.

$ gem install metrical

Installer cette gem va également installer un certain nombre de dépendances. Une fois cela terminé, nous pouvons lancer la commande metrical dans le dossier de l'application et cela va faire tourner un ensemble de métriques sur le code de cette dernière via metric_fu. En faisant cela, nous allons probablement voir un certain nombre d'erreurs listées en sortie mais, dans la majeur partie des cas, elles peuvent être ignorées tant que la commande fonctionne. Il est facile de voir si la commande a fonctionné car elle ouvre le navigateur web.

La première page liste les différents outils de métrique que metric_fu a lancé. Nous pouvons cliquer sur chacun d'eux pour voir le résultat qu'ils ont généré. Par exemple, si nous regardons Reek, nous pouvons voir de nombreuses informations utiles sur les parties de l'application qui peuvent être améliorées.

Maintenant, regardons un autre outil, Rcov. Parmi les outils utilisés par Metrical, c'est celui dont l'échec est le plus probable. Cela est dû au fait qu'il nécessite les tests et specs de l'application. Si nous le lançons sur Railscasts, le taux de couverture du code sera de 0.0%. Le problème est que le code utilise Ruby en version 1.9, que Rcov ne supporte pas encore. Avant de regarder les alternatives, nous allons retirer Rcov de la liste des outils. Pour configurer metric_fu au travers de Metrical, nous devons ajouter un fichier .metrics dans le dossier de l'application.

MetricFu::Configuration.run do |config|
        config.metrics -= [:rcov]
end

Lorsque nous lançons metrical de nouveau, nous allons voir moins d'erreurs et la section Rcov ne fera plus partie des résultats. La couverture de code est une métrique utile, qu'allons nous donc choisir pour remplacer Rcov ? Il existe quelques alternatives que nous pouvons utiliser, CoverMe et SimpleCov. Les deux produisent de bons résultats mais nous choisirons SimpleCov, pour le simple fait qu'il est plus facile à mettre en place. Commençons par ajouter la gem dans le fichier Gemfile.

group :test do
  gem 'simplecov', '>=0.3.8', :require => false
end

Ajoutons ensuite les deux lignes suivantes au fichier test ou spec helper.

require 'simplecov'
SimpleCov.start 'rails'

Comme d'habitude, lorsque l'on ajoute une gem à une application, nous devons lancer bundle pour s'assurer que la gem est installée. Une fois installée, nous pouvons lancer rake spec pour faire tourner les specs de l'application. Ouvrons ensuite le fichier coverage/index.html pour voir le résultat.

Cela nous donne un moyen simple de voir quels fichiers ont le moins de couverture par les tests ou les specs. Les pires fichiers sont listés en premier et si l'on clic sur l'un d'eux, par exemple comments_controller, on peut voir exactement quel code est couvert et quel code ne l'est pas.

Nous pouvons ainsi voir précisément quel code n'est pas couvert et modifier les tests ou le code en conséquence afin d'améliorer le pourcentage de couverture.

Nous avons maintenant une solution satisfaisante en ce qui concerne la couverture de code. Nous allons voir maintenant les deux nouvelles métriques fournies par metric_fu, le rapport des Bonnes Pratiques et les Hotspots.

Les Hotspots nous donnent un aperçu des différents fichiers, classes et méthodes de notre application, listant les pires en premier. Ce choix se base sur un certain nombre de facteurs, Reek et Flog en particulier, et est un bon point de départ pour déterminer les zones du code qui requièrent notre attention.

Le rapport des Bonnes Pratiques nous indique les parties de notre code qui ne respectent pas les bonnes pratiques.

Le résultat de ce rapport semble un peu étrange lorsqu'il est consulté via le navigateur. Nous pouvons utiliser la gem directement, sans passer par metric_fu. Puisque nous avons installé Metrical, nous devrions déjà l'avoir à notre disposition mais, dans le cas contraire, nous pouvons l'installer comme ceci :

$ gem install rails_best_practices

Lorsque nous lançons la commande ci-dessus, il nous est conseillé de visiter le site Rails Best Practices. Jetons donc un œil.

Le site Rails Best Practices est intéressant et contient une longue liste des bonnes pratiques que nous pouvons suivre pour améliorer nos applications Rails. Dans l'onglet “Implemented” se trouvent les pratiques utilisées par la gem et qui seront vérifiées lorsque nous lançons la commande rails_best_practices.

Lorsque nous lançons cette commande, nous obtenons une liste de suggestions en rouge.

$ rails_best_practices 
Analyzing:     100% |oooooooooooooooooooooooooooooooooooooooooo| Time: 00:00:00
<span style="color:#C00;">./app/controllers/comments_controller.rb:53 - move model logic into model (errors use_count > 4)
./app/views/comments/index.rss.builder:10 - law of demeter
./app/views/comments/index.rss.builder:10 - law of demeter
./db/schema.rb:15 - always add db index (comments => [user_id])
./db/schema.rb:71 - always add db index (spam_reports => [comment_id])
./app/controllers/comments_controller.rb:28,32,41 - use before_filter for edit,update,destroy
...</span>

Le text rouge peut piquer un peu les yeux. Alternativement, nous pouvons demander à ce que le résultat soit sous la forme HTML et que les noms de fichiers soient des liens permettant d'ouvrir les fichiers dans TextMate.

$ rails_best_practices -f html --with-textmate

Cela va générer un fichier HTML nommé rails_best_practices.html que nous pouvons ouvrir dans notre navigateur.

La commande a trouvé 26 erreurs dans cette application. Si nous cliquons sur n'importe quel nom de fichier, le fichier correspondant sera ouvert dans TextMate. Cliquer sur un message d'erreur nous mènera à la page correspondante du site Rails Best Practices, nous permettant d'obtenir une description du problème ainsi que quelques conseilles d'amélioration du code. Il ne nous reste plus qu'à parcourir la liste et voir comment améliorer notre code.

Comme toutes les métriques, ces recommandations ne sont pas à prendre au pied de la lettre. Le fait qu'une technique soit considérée comme une bonne pratique dans le cas général ne signifie pas que ce soit le mieux pour notre application. Nous devons considérer la liste fournie comme un guide permettant de trouver les zones qui peuvent être améliorées. Ne vous fixez pas l'objectif de faire descendre cette liste à zéro. Cela s'applique à toutes les métriques, ne les prenez pas pour argent comptant sans prendre en considération le bien fondé de leur application sur votre code. Assurez vous que ces recommandations apportent un plus à votre application. La métrique doit être utilisée comme un indicateur de ce qui peut être perfectionné.