There’s a perfectly good explanation for why I have been MIA on here for the past month. My apologies. I started working on a really huge project for work. By huge I mean the code base is enormous and in a language I have only just started to get familiar with. I had to take my time to learn the ins and outs of the components, how everything works seamlessly together and of course learn more C++ in the process.
I have worked on code bases written by other engineers before, actually in all my career. I have never actually written an entire project myself from scratch when it comes to work. What I’ve done is added new components, functionalities and cleaned up in an already existing project. The difference this time was that this is the largest one I have been a part of, and with the most contributors. Let alone in a language that has a steeper learning curve.
All in all. I thought I should share some insights on how to quickly familiarize oneself with a large project quickly and efficiently.
Start with the tests
All large projects almost always have tests. Tests are meant to try the code’s functionality against many different scenarios. For instance, if your project has a signing in functionality, then you’d have to check it against scenarios like; what happens when a user tries to sign in and they don’t have an account; when a user signs in with the correct account but wrong password and vice versa. Tests are broader than that, but that is just a very simple explanation.
I found that when I went into the project’s tests, I had a summary of all the available functionalities within the project. Everything that the project did and was expected to do. That way I was able to create some sort of map to all the methods within the code and could easily access them from there. Large projects have tons of files. Each file normally holds a class and a class has a couple of methods in it. The thing is to know how all the different classes and methods are connected to seamlessly work together.
Since there usually isn’t a detailed user guide to a code base, I trust the unit tests enough to tell me what some methods do and their expected results.
Solve bugs
Another very effective way to get familiar with a large project is to pick an existing bug and solve it.
“How and I don’t know where anything is and what does what?”
Solving bugs is a practical way to learn a code base because from this, you are investigating the code and will probably add to or remove from it. Either way, you are now a contributor. Not only do you recreate the bug probably on the user interface of the project, but you also go thorough the code to identify exactly where the bug is coming from and what is causing it. This way of learning teaches you the project brick by brick because you will most likely investigate a single unit that houses the location of the bug.
Write your own documentation
Since you’re on new territory, I find it very helpful to document everything you discover as you go along. It could be writing comments, or having your own .md file on the side where you note down in your own words what you think a class, or a method does. Another way is to draw a ‘map’ that shows the connections of the classes and methods. With little comments summarizing what they do.
This will act as a reference point as you continue to work on the project and everything just sticks faster that way.
Always remember to keep your documentation/ map updated because it beats its purpose if it’s wrong.
