Code discovery: how to find code that you need to fix or extend

Discovering code. This is something that we do almost every day, especially at the start of a new bug fix or feature request. It surprises me how often I come across engineers who don’t have a clear process for discovering code. If you’ve been a developer for some time, I’m sure you’ve heard the saying “Code is read more often than it is written,” but how do you find the code that needs to be read? How long does it take you to get there?

Before we start, I should say that this post is primarily for Ruby on Rails and React engineers, although there probably are similar tools/processes for the language of your choice.

Discovering server code

We receive a bug card to fix some backend business logic. What’s our next step?

What not to do

Let’s say the bug is around searching for candidate applications — the wrong candidates are being surfaced when filtering for a specific department. Since the bug is around searching for candidates with a department filter, we might start looking for directories or files with keywords such as “candidate search” or “department filter” in order to find the file where the bug exists.

This is a guessing game that will often lead you down rabbit holes and waste your time. In an ideal world where file names and directories are perfectly named and organized, this approach may work, but it’s still an unreliable approach that will often take you down the wrong path.

Rails Panel

A better approach that most engineers will take instead is to reproduce the bug in the UI, identify the controller and action from the server logs, and step through the call stack to identify the bug. This is a tried and true approach that will always take you to the correct location of the problematic code but Rails Panel can make it much easier to find the controller action in question by eliminating the need to parse and scroll through long server logs in order to find it.

To use Rails Panel, follow these installation steps and then click the Rails tab in Chrome Dev Tools. Then you can navigate to any page in your app and it will show you the organized version of the server log information.

With Rails Panel, you can easily see the controller and action that rendered the page. Some helpful tabs that Rails Panel provides are:

• Params — lists all of the params sent to the server
• ActiveRecord — lists every database query along with how long each query took (this is especially helpful when debugging performance issues)
• Rendering — lists every ERB file that was rendered

Again, you can get the same information from your server logs but it’s much easier to get it from Rails Panel without having to scroll through a bunch of logs.

Discovering front end code

We receive a card to fix a bug related to the search bar on the integrations page.

What not to do

Most engineers are very familiar with the following approach: right-click and inspect element to find a relevant id or class name, then use this to do a global find in the editor in order to identify the correct source. While this isn’t a terrible approach, it will often lead you down the wrong path.

When we take this approach, we’re relying on finding a unique identifier on the page that may not always be present. In the case pictured above, there is a search-input-container class name and a search_input id, but this search bar is a generic component that is used on many different pages, so searching for these keywords won’t directly take you to the correct source file. A more efficient approach would be to use React Dev Tools.

React Dev Tools

After installing React Dev Tools, open up Chrome Dev Tools and click the Components tab.

As demonstrated in the gif above, click the select element icon and then hover your mouse over the element you’d like to inspect, and React Dev Tools will show you which component renders that element (which in this case is SearchBar). You can then scroll up to see which parent components render the SearchBar . Using this approach with React Dev Tools allows you to work backwards from any element to ultimately find the source file you are looking for.

Other benefits to using React Dev Tools include displaying the props being passed to each component, the ability to update the props to different values as you troubleshoot a bug, a profiler tab that you can use to debug rendering performance issues.

Side note: If you use styled components to style your React components as we do at Greenhouse, you’ll want to install the babel-plugin-styled-components plugin. Otherwise, React Dev Tools will show things like styled.div all over the place instead of using the displayName of your styled component. For more info — https://styled-components.com/docs/tooling#better-debugging

Please feel free to share any tips on how you discover code in the comments below. I’m always trying to learn new ways to improve my process in this area.

We’re hiring!