Analyzing Codebases for Fun and Profit

What is the work that you're doing today in your day job?

I am currently working at Castlight Health, filling the role of an architect. I mostly work on company-wide initiatives, helping teams simplify and design their systems. Because of this, I constantly jump into legacy codebases to understand and redesign them. I recently spent time developing stream processing and event-driven systems. 

What are the takeaways from your session? 

My goal is to share techniques that have been helpful for me when jumping into complex codebases within time constraints. I feel like some engineers tend to rely too heavily on StackOverflow. Time pressure appears to be a primary factor, but also some of these codebases are very complex. If you are working on internal projects, one can only hope someone wrote some documentation and the tribal knowledge remains somewhere. For open-source projects, you file a ticket and hope someone will pick it up. Given minimal time and resources, how can you quickly get some level of comfort with the source code? I hope that the ideas and techniques I provide here will resonate and help someone do this better. Being able to quickly understand a code base is a critical skill for being an effective engineer.

Do you show specific developer tools or are you using tips on how to work with the team to get you up to speed? What focus do you have? 

I don't use anything developers don’t already have. Some of the pre-work before digging into codebases themselves may be obvious. You want some context, such as working with a developer who knows the code, reading the documentation, or trying out some simple examples. However, documentation and engineers are often limited, and lots of details and history only live in the codebases. Debuggers and other runtime observations often help identify an entry point or code branch you want to investigate. Most modern IDEs provide a massive advantage for analyzing codebases. 

My main focus is on identifying entry points and key functions of interest, not getting stuck understanding functions of passive interest, identifying potential items of debt, and how to share that knowledge with others. With Castlight, we invested more into using Kafka for mission-critical functions in the last few years. While, luckily, Kafka has a vast community and documentation, we were relying on it for tasks that have a significant impact on the business, so we had to ensure we understood its nuances, specifically around the Kafka consumer. So how do we up our knowledge as quickly as possible to somewhere between surface-level and active contributor?

Do you stick to static code reading, or do you ever fire up the debugger to see what it does, where the data flows?

It depends on my focus; if I am debugging a problem or identifying a given branch and entry-point, I leverage debuggers pretty heavily. In the world of Spring Boot, understanding all the entry points has become more complex with auto-configuration, which runtime debugging can aid in identifying. Sometimes, however, you don’t have the luxury of debugging, or setting up a debuggable environment would take longer than static code analysis.