How to onboard onto a large codebase.

It did not make much sense to me the first time I heard about a codebase but a codebase simply refers to a collection of source code that is used to build a particular software system, application or software component.

Perhaps up until now, you might have on a product building it from scratch but onboarding onto an existing code base means you building on top of already existing code built by other developers.

During the Andela deferral program, we were tasked to work on a code base for a product called iReporter built with Python and Flask by another developer.

We were required to go through the product, identify bugs, missing features or any improvements we could add to the product.

Steps we took to onboard onto the code base.

1. Understanding the product.

Having a clear understanding of what the application does, what problem it is meant to solve is very important. luckily for us, we were at an advantage, since we had worked on the same product during the Bootcamp on our individual projects, so we had an idea. However, you can always make use of the project rubric/documentation to gain an understanding of why the application exists and why it has features designed to function a certain way.

2. Read the Documentation.

In order to understand the product, we made use of the project documentation and the readme on the GitHub repository to gain a clear understanding of the application.

As was the case, incomplete or poorly done documentation slows down the process of understanding the application. A good README for a project explains clearly, steps by step how the user can set up. Unfortunately for us, we had to fill in the missing lines, since the README was incomplete.

3. Trying out the product.

After having gone through the project’s documentation, we set up the project and tried out the API using Postman, an API development testing environment.

Were able to identify:-

• What was working,
• what was broken,
• what could be fixed and,
• what could be improved.

4. Doing a quick reviewing of the code and running the tests.

After having had a quick visual experience of the application, with the insight gained, we went through the code. During this process, we reviewed the application structure in relation to the Model View Controller (MVC) pattern. We also checked for compliance with PEP8 standard.

Here is a screenshot of the Polly we created on Slack for issues to work on.

Polly showing issues identified during the code base review.

5. Running tests.

Since the Test-drive development (TDD) approach was used on the code base, we run the tests to further gain a better understanding of what worked and what did not. Since tests also act as additional documentation, we went through them to better understand the business logic of the application.

6. Assigning and prioritizing tasks.

After having reviewed and tried out the code base, we were able to identify the edge cases and prioritized them. Each team member picked a task to work on. This being a team project It would be rather unfair for me not to introduce my team.

The team.

• Kajura Jude. (The Technical Team Lead)
• Kalule Arthur (me, Team Lead).
• Mugaya Joel Patrick.
• Innocent Lou Bison.
• Atama Zack.
• Nelson Mwiru.

7. Understanding the tools used.

The code base both used and required one to have a better understanding of different tools in order to collaborate better as a team.

1. Slack — a collaboration hub for work.
2. Heroku — a cloud application platform (Deployment environment).
3. Github — Version control.
4. Travis-CI — Testing environment.
5. Code Climate — Checking Code standard.
6. Coveralls — Test coverage.
7. Pivotal Tracker — Project management.
8. Postman — API development and testing.

Conclusion.

Onboarding onto an existing code base requires that first, you gain a better understanding of the product’s business logic and edge cases before you dive into working on it. Also since different developers and organisations have different code styles, it is important for you to be able to adopt a different code style whenever required. Much as having a code style and sticking to one is very important, ensuring that the code meets the best practice standards takes precedence over trying to personalize the code base to your own code style.