Find unused code in a Rails app

Question

How do I find what code is and isn't being run in production ?

The app is well-tested, but there's a lot of tests that test unused code. Hence they get coverage when running tests... I'd like to refactor and clean up this mess, it keeps wasting my time. I have a lot of background jobs, this is why I'd like the production env to guide me. Running at heroku I can spin up dynos to compensate any performance impacts from the profiler.

Related question How can I find unused methods in a Ruby app? not helpful.

Bonus: metrics to show how often a line of code is run. Don't know why I want it, but I do! :)

Dardan

By unused do you mean: (A) there is no way for the method to be called from the within the web app or (B) it is not used by your visitors? – Blackman

both, but I value B most. Thanks! Any suggestions to B? – Dardan

If B's what you're after, sounds like you are reaching for an analytics tool more than code-coverage, no? Or some kind of hybrid. Dunno if anyone's invented this, if we can't even quite name it. +1 for interesting. – Subtorrid

This is a great question. I don't have an answer but I'm EAGERLY following this post to see what the community comes up with. I've inherited a legacy application and if I ever had the time I'd love to start cleaning it up. – Bush

If you have feature / system or at least request specs, it might already help a lot to look at the test coverage only for these higher level specs. If code is touched by a feature spec, it is very unlikely to be dead. All test not covered by feature specs could be inspected: is a test missing, or is it really dead? – Speakeasy

Answer 1

Under normal circumstances the approach would be to use your test data for code coverage, but as you say you have parts of your code that are tested but are not used on the production app, you could do something slightly different.

Just for clarity first: Don't trust automatic tools. They will only show you results for things you actively test, nothing more.

With the disclaimer behind us, I propose you use a code coverage tool (like rcov or simplecov for Ruby 1.9) on your production app and measure the code paths that are actually used by your users. While these tools were originally designed for measuring test coverage, you could also use them for production coverage

Under the assumption that during the test time-frame all relevant code paths are visited, you can remove the rest. Unfortunately, this assumption will most probably not fully hold. So you will still have to apply your knowledge of the app and its inner workings when removing parts. This is even more important when removing declarative parts (like model references) as those are often not directly run but only used for configuring other parts of the system.

Another approach which could be combined with the above is to try to refactor your app into distinguished features that you can turn on and off. Then you can turn features that are suspected to be unused off and check if nobody complains :)

And as a final note: you won't find a magic tool to do your full analysis. That's because no tool can know whether a certain piece of code is used by actual users or not. The only thing that tools can do is create (more or less) static reachability graphs, telling you if your code is somehow called from a certain point. With a dynamic language like Ruby even this is rather hard to achieve, as static analysis doesn't bring much insight in the face of meta-programming or dynamic calls that are heavily used in a rails context. So some tools actually run your code or try to get insight from test coverage. But there is definitely no magic spell.

So given the high internal (mostly hidden) complexity of a rails application, you will not get around to do most of the analysis by hand. The best advice would probably be to try to modularize your app and turn off certain modules to test f they are not used. This can be supported by proper integration tests.

Periodicity

Additionally, if you have a really good test suite, you may see 100% code usage through unit tests, but a lot of it may no longer be used in production. I've had issues with this before, because you end up maintaining code during refactoring to make it compatible with api changes, when really the code could just be deleted. I don't have a good answer to that problem, just wanted to chime in and commiserate. – Heman

thx Scott. DRY, SRP, law of demeter and so on- code deletion is essential. Nice writeup Holger. – Dardan

anyone have experience with setting up rcov/simplecov in production? We use 1.9.2. Oh, it runs on heroku, adding the read-only problem... – Dardan

Answer 2

Checkout the coverband gem, it does what you exactly what are you searching.

Counterintelligence

@Dimitry, looks VERY promising, I'll give it a shot on a few apps and report back – Dardan

If you need to cleanup I18n locales, then you can use this gem: github.com/livingsocial/humperdink – Counterintelligence

@Dardan Any results to report back on with the Coverband gem? Sincerely, Interested Party. :) – Lucio

Answer 3

Maybe you can try to use rails_best_practices to check unused methods and class.

Here it is in the github: https://github.com/railsbp/rails_best_practices .

Put 'gem "rails_best_practices" ' in your Gemfile and then run rails_best_practices . to generate configuration file

Coblenz

Answer 4

I had the same problem and after exploring some alternatives I realized that I have all the info available out of the box - log files. Our log format is as follows

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

So I created a simple script to parse this info

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

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

Which produced results of how often an given controller#action was accessed.

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

Next step is to compare it to the list of all controller#action pair in the app (using rake routes output or can do the same script for testing suite)

Michaelmichaela

Answer 5

You got already the idea to mark suspicious methods as private (what will maybe break your application).

A small variation I did in the past: Add a small piece code to all suspicious methods to log it. In my case it was a user popup "You called a obsolete function - if you really need please contact the IT". After one year we had a good overview what was really used (it was a business application and there where functions needed only once a year).

In your case you should only log the usage. Everything what is not logged after a reasonable period is unused.

Obeded

Answer 6

I'm not very familiar with Ruby and RoR, but what I'd suggest some crazy guess:

• add :after_filter method wich logs name of previous called method(grab it from call stack) to file
• deploy this to production
• wait for a while
• remove all methods that are not in log.

p.s. probably solution with Alt+F7 in NetBeans or RubyMine is much better :)

Ranitta

Neither RubyMine nor NetBeans understand metaprogramming. It saying "no usage found" doesn't necessarily mean that there are no usages. This is a huge app, I'm looking for a more robust and proven approach, not writing my own production coverage tool. – Dardan

Answer 7

Metaprogramming

Object#method_missing

override Object#method_missing. Inside, log the calling Class and method, asynchronously, to a data store. Then manually call the original method with the proper arguments, based on the arguments passed to method_missing.

Object tree

Then compare the data in the data store to the contents of the application's object tree.

disclaimer: This will surely require significant performance and resource consideration. Also, it will take a little tinkering to get that to work, but theoretically it should work. I'll leave it as an exercise to the original poster to implement it. ;)

Disclaimer

Answer 8

Have you tried creating a test suite using something like sahi you could then record all your user journies using this and tie those tests to rcov or something similar.

You do have to ensure you have all user journies but after that you can look at what rcov spits out and at least start to prune out stuff that is obviously never covered.

Shrine

I use Capybara for this purpose. Just have to watch out for tests that instead of navigating to some feature via UI just visit a fixed URL. They could be visiting a feature phased-out in production production by removing links. – Huguenot

Answer 9

This isn't a very proactive approach, but I've often used results gathered from New Relic to see if something I suspected as being unused had been called in production anytime in the past month or so. The apps I've used this on have been pretty small though, and its decently expensive for larger applications.

I've never used it myself, but this post about the laser gem seems to talk about solving your exact problem.

Breastfeed

Answer 10

mark suspicious methods as private. If that does not break the code, check if the methods are used inside the class. then you can delete things

Phonation

You could always run the tests before deploying to production... Although I realize that this is tedious and does not scale well. – Typecast

@BradWerth any reasonable production app should be using a CI tool such as CircleCI or Travis to run test suite against builds prior to production deploys. – Plunkett

@lacostenycoder, yeah, no kidding, but this wasn't as common 9+ years ago... – Typecast

Answer 11

I found the debride gem worked well for this https://github.com/seattlerb/debride

Corettacorette

Answer 12

It is not the perfect solution, but for example in NetBeans you can find usages of the methods by right click on them (or press Alt+F7).
So if method is unused, you will see it.

Kantianism

this is the exact same answer as one of those of the question I referenced as "not helpful". See mye comment to aleksey for the reasons. – Dardan