In software development you are destined to deal with lots of code that is not written by you. What would be more stressful than debugging the code that you barely understand. You might have been in the situation where you have been assigned a bug and you have to traverse through lots of file which you have no idea of, just get to root cause of the issue. Being in these situations many times, I have learned few tips and tricks for debugging and would like to share it here.

**Checking where the method causing a problem exists.**

In some situation you might get a name of the method which is not returning a proper output, but you can't find the method definition anywhere in the code. Until and unless you find the method definition forgot about finding the bug and fixing it. You might not be able to locate the method definition due to various reasons. Most common once are - Method definition is present in some gem - Method is added dynamically using metaprogramming

Ruby provide a great way of finding the filename and line number of where the method is defined. You just have to call a method method on the object which responds to the method, it will give a Method class object in return. You can call source_location method on this object to get the location where method is defined.

object.method(:some_method).source_location # ["/Users/Organization/project_name/app/models/some_file.rb", 450]

Bonus tip: You can also check the number of arguments this method takes by calling arity method on Method class object
Note: source_location will return nill if method is defined using C language and not in Ruby.

Debugging rails controller issue.

If you have worked in rails, you would know what controller filters or callbacks are(before_action, after_action etc). Controller filters are great way of refactoring the code. But as each coin has it other side, controller filters are no exception. More and more filters in the controller, harder it becomes to debug it. If we are inheriting a controller from other controller and so on, then all the filters of each controller would be run in sequence from top to bottom. When it comes to debugging such code, it might cause you sever headache in a best case or a total brain damage in the worst case :) Jokes apart, but it's really difficult situation to be in. You have to traverse entire class hierarchy of controller and list down all the filters which are run for an action. Your task gets more difficult when some filters are not in your source code but are declared inside some gem code. Rails provide a method named `_process_action_callbacks` to list down all the controller filters that would be executed for particular controller.

For more information check this simple code sample

Once you have a name of the method you can use method and source_location method to check where that method is defined and debug the code further.

Assets not getting compiled.

Few months back I faced a issue where in everything was working in local environment, but when I tried to deploy the code, asset compilation would fail. There were few js files that were present in the PR and I wanted to check which file is causing an issue. As we have lots of js file, compiling all of them would take time and I just wanted to check files in the PR that I was deploying. If you are using uglifier gem to compress your js file, you can use below command to compress individual file and check if there is any exception during compression process. 
 Uglifier.compile(Rails.application.assets.find_asset('some_file_name.js').to_s)

Debugging is a art of drilling down through code base to reach that single line which is causing your system to malfunction.