Trouver du code inutilisé dans une application Rails

Question

Comment savoir quel code est ou n'est pas exécuté ? en production ?

L'application est bien testée, mais il y a beaucoup de tests qui testent inutilisé code. Ils sont donc couverts lors de l'exécution des tests... J'aimerais refactoriser et nettoyer ce désordre, qui me fait perdre mon temps. J'ai beaucoup de tâches en arrière-plan, c'est pourquoi j'aimerais que l'environnement de production me guide. En tournant sur heroku, je peux faire tourner des dynos pour compenser les impacts de performance du profiler.

Question connexe Comment trouver les méthodes inutilisées dans une application Ruby ? n'est pas utile.

Bonus : des mesures pour montrer la fréquence d'exécution d'une ligne de code. Je ne sais pas pourquoi je le veux, mais je le veux ! :)

Answer 1

Dans des circonstances normales, l'approche consisterait à utiliser vos données de test pour la couverture du code, mais comme vous dites que vous avez des parties de votre code qui sont testées mais qui ne sont pas utilisées dans l'application de production, vous pourriez faire quelque chose de légèrement différent.

Par souci de clarté, tout d'abord : Ne faites pas confiance aux outils automatiques. Ils ne vous montreront que les résultats des éléments que vous testez activement, rien de plus.

Cette mise au point étant faite, je vous propose d'utiliser un outil de couverture de code (comme rcov o simplecov pour Ruby 1.9) sur votre application de production et mesurer les chemins de code réellement utilisés par vos utilisateurs. Bien que ces outils aient été conçus à l'origine pour mesurer la couverture des tests, vous pouvez également les utiliser pour la couverture de la production

Si l'on part du principe que tous les chemins de code pertinents sont visités pendant la durée du test, on peut supprimer les autres. Malheureusement, cette hypothèse ne se vérifiera probablement pas entièrement. Vous devrez donc continuer à appliquer votre connaissance de l'application et de son fonctionnement interne lorsque vous en supprimerez des parties. Ceci est d'autant plus important lors de la suppression de parties déclaratives (comme les références de modèles) car celles-ci ne sont souvent pas directement exécutées mais seulement utilisées pour configurer d'autres parties du système.

Une autre approche, qui pourrait être combinée avec la précédente, consiste à essayer de remanier votre application pour en faire des fonctions distinctes que vous pouvez activer ou désactiver. Ensuite, vous pouvez désactiver les fonctionnalités qui sont suspectées d'être inutilisées et vérifier si personne ne se plaint :)

Enfin, vous ne trouverez pas d'outil magique pour effectuer votre analyse complète. En effet, aucun outil ne peut savoir si un certain morceau de code est utilisé par des utilisateurs réels ou non. La seule chose que les outils peuvent faire est de créer (plus ou moins) des graphes d'accessibilité statiques, vous indiquant si votre code est appelé d'une manière ou d'une autre à partir d'un certain point. Avec un langage dynamique comme Ruby, même cela est assez difficile à réaliser, car l'analyse statique n'apporte pas beaucoup d'informations face à la méta-programmation ou aux appels dynamiques qui sont fortement utilisés dans un contexte de rails. C'est pourquoi certains outils exécutent votre code ou tentent d'obtenir des informations à partir de la couverture des tests. Mais il n'y a certainement pas de formule magique.

Ainsi, étant donné la grande complexité interne (le plus souvent cachée) d'une application ferroviaire, vous n'aurez pas la possibilité d'effectuer la plupart des analyses à la main. Le meilleur conseil serait probablement d'essayer de modulariser votre application et de désactiver certains modules pour tester s'ils ne sont pas utilisés. Ceci peut être soutenu par des tests d'intégration appropriés.

Answer 2

Vous pouvez peut-être essayer d'utiliser rails_best_practices pour vérifier les méthodes et les classes inutilisées.

Le voici dans le github : https://github.com/railsbp/rails_best_practices .

Mettez 'gem "rails_best_practices" ' dans votre Gemfile et exécutez ensuite rails_best_practices . pour générer un fichier de configuration

Answer 3

Consultez le site bande de recouvrement gem, il fait ce que vous cherchez exactement.

Answer 4

J'ai eu le même problème et après avoir exploré quelques alternatives, j'ai réalisé que j'avais toutes les informations disponibles dans la boîte - les fichiers journaux. Le format de notre journal est le suivant

Dec 18 03:10:41 ip-xx-xx-xx-xx appname-p[7776]:   Processing by MyController#show as HTML

J'ai donc créé un simple script pour analyser cette information

zfgrep Processing production.log*.gz |awk '{print $8}' > ~/tmp/action

sort  ~/tmp/action | uniq -c |sort -g -r > ~/tmp/histogram

Ce qui a permis d'obtenir des résultats sur la fréquence d'accès à une action d'un contrôleur donné.

4394886 MyController#index
3237203 MyController#show
1644765 MyController#edit

L'étape suivante consiste à le comparer à la liste de toutes les paires contrôleur#action dans l'application (en utilisant rake routes output ou en faisant la même chose script pour la suite de tests).

Answer 5

Je ne suis pas très familier avec Ruby et RoR, mais ce que je suggérerais, c'est une supposition farfelue :

• ajouter :after_filter méthode qui enregistre dans un fichier le nom de la méthode appelée précédemment (à partir de la pile d'appels)
• déployer en production
• attendre un peu
• supprimer toutes les méthodes qui ne figurent pas dans le journal.

p.s. La solution avec Alt+F7 dans NetBeans ou RubyMine est probablement bien meilleure :)