Whether you joined a new team, got a new job, or started to take part in an open source project, you’re going to find yourself dealing with a large and unknown codebase. There is a ramp-up period where you’ll be spending your time to understand the code base before you can start to be productive and contribute more. This ramp-up period is unavoidable even for the most skilled developers. Although you can’t avoid the ramp-up period you can make it shorter. Here are 7 tips to learn an existing codebase faster.
1. Find a Mentor
Find someone who is already familiar with the code base and ask them if they are willing to be interrupted by you to answer your questions. Don’t stop there though, it is best that this relationship is made aware so that the project lead will ease off the pressure on your mentor during this time.
In some cases, it might not be easy to find a mentor. Perhaps everyone in the team is too busy to help you out. Or maybe nobody wants to deal with all the silly questions you will be asking. Regardless, finding a mentor should be one of your top priorities when diving into a new code base.
Without a mentor, you’ll take much longer to do anything within the code base. You’ll be going in the wrong direction multiple times before you find the right path. With a mentor, you can easily reduce those wrong paths and sometimes even start off on the right path.
2. Look for Pair Programming Opportunities
If you are diving into a new code base a pair programming session with someone already familiar with the code base will accelerate your learning. Instead of fumbling through the code base to learn how the code works, you can learn from your partner’s experience. Those mistakes that you’ll probably make if you decide to be a lone wolf in learning the code base, your partner probably have made those mistakes in the past. Think of how much time you can save if you can be learning from your partner’s mistakes.
Although pair programming is a great opportunity for you to quickly ramp up to a code base, they are rare to come by. Pair programming often has to be part of the work culture for them to happen. But if you do find yourself in an environment where pair programming does take place, take advantage of it.
3. Get an Overview
Find someone (your mentor if you have one) to give you a high-level overview of the system such as its design and style. Find out what architecture the code base employs and why. Find out where the core logic of the application is located. If there are third-party frameworks and libraries, get a list of them and study each one to understand what their roles are in the code base.
4. Understand the Why of the Application
Understand what problems the application is trying to solve. Understand who uses the application and the problem that they face. Figure out and understand the business domain of the application because it will provide insight into why features exist and why code might be written in a certain way.
By understanding the product and what problems it is trying to solve, it will give you a better context for the code base. This will allow you to be more user-focused, which results in code that aims to meet the needs of the users.
5. Start with Small Quests
Don’t go diving into the code base by working on a new feature. That is just asking for a whole lot of trouble for you and your team. Instead, take a tiny step and work on a bug fix. Fixing bugs don’t sound fun, but your priority when moving into a new code base is to become familiar with it. Being able to fix bugs means you are able to understand a small portion of the code base.
As you progress through a few small quests, you can move into something more exciting such as tiny features. Writing a feature even a small one requires understanding how a certain part of the relevant codebase works. As you continue to fix bugs and write small features, more and more pieces will connect and eventually you’ll have enough bits and pieces filled to be proficient in the code base.
6. Talk It Out
Find other people who have worked in the code base or currently working on it. Tell them in your own words how you understand the code base is working. They’ll either correct you or offer how they understand the code base. In either case, it is a win, you now know if your understanding is correct or you gain another perspective on how the codebase works.
7. Have a Don’t-Get Stuck Rule
When you are trying to fix a bug or write a tiny feature, ask someone (your mentor) for help if you get stuck for more than 30 minutes. Always try to solve it yourself first, but if you still have no idea after 30 minutes then you will likely not figure it out for hours. So, at the 30-minute mark, you’ll benefit yourself and the team more by asking for help.
The don’t-get stuck rule sounds simple, but it is surprisingly difficult to follow. The reason is that when you get stuck, you have a tendency to try to stick to it and fix it yourself. Being a lone wolf is not what you want to do, because great software is built by great teams, not great developers. So, next time you get stuck go ask for help, the benefits will probably outweigh the negatives.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
Have you used some of these tips for learning a code base? How well does it work for you?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.