Exercises to Maintain A Healthy Codebase

How we keep a healthy codebase while delivering quickly.

Whether you like it or not, code review is a critical part of software development.

It’s one of the ways to maintain the health of your codebase and minimize the number of problems that your app might experience in the future. Furthermore, it encourages a knowledge-sharing culture among your developer team.

When it comes to code review, I’d like to believe that each organization already has its own set of rules and best practices that suit the working style of the software engineering team. So, rather than calling this piece a “guide” or something along those lines, I’d like to think of it as a sharing based on my experience at DK.

This article will cover:

• Why we need a Code Review
• Guide and tips for Reviewer
• Guide and tips for Reviewee
• Pair Programming

Let’s go!

At DKatalis, we’re using a Git-based DevOps cycle hosted on GitLab. When a developer has finished working on a new feature of bug fixing, etc, they need to merge it to the main branch.

However, some defects introduced in newly-written code can be extremely difficult for the tester to detect. This is especially true for asynchronous code, as it has different callback times in the test and production environments. A code that performs well in a testing environment may encounter issues, such as bugs, when deployed to production. All MRs will undergo a review process as the following:

This way, we can ensure that our codes are well-written, tested, and follow the agreed style guidelines. It also helps the knowledge-sharing process and sometimes, guides new devs to familiarize themselves with the development flow at DKatalis.

Now that you know Why we do Code Review at DKatalis, let’s move to the How.

Every engineer knows that code reviews can sometimes cause a little friction within the team. There might be slight disagreements on whether a certain naming style is right or wrong; or whether a review actually fixes an issue or exacerbates it. This, of course, contradicts the main goal of code review in the first place and raises the importance of having a guideline for the process.

We mostly adopt our guidelines from Thoughtbot, but also add some new ones based on inputs from our developers.

• It’s not about you. We live by this quote: “Remember that you are here to provide feedback, not to be a gatekeeper”. Before giving feedback, seek to understand the author’s perspective.
• It’s iterative. You can open a discussion by clicking “Add comment” on changes
• Give proper closure and appreciation. When a discussion has been resolved (by code changes or dev explanation), the one who creates the comment should resolve the discussion. Then, don’t forget to sign off on the MR (merge request) by giving LGTM (Looks Good to Me) / thumbs up (👍) when the review is done.

What if you are at the receiving end of the stick? Here’s the conduct when that happens:

• Get in the right mindset. Always remember this phrase: “Don’t take it personally. The review is of the code, not you.”
• Be well-prepared. You can look through the code yourself once or twice before asking others. Sometimes you can spot the majority of code errors yourself. You can briefly explain what you gonna do (purpose) about your code.
• Be proactive. You need to notify other devs to help review your code. Don’t hesitate to connect to the reviewer if needed, maybe follow up on a comment the reviewer adds.
• Don’t submit too many changes at once for review, as you can do it progressively.

Our code review process might be similar to others in the industry, although some might differ. What might distinguishes us is that we make the process more efficient by enforcing Pair Programming.

How, you might ask? Let’s start with understanding how the program works at DKatalis.

In short, pair programming is where two or more developers pair up to work on a project together, in the specific roles of driver and navigator. The Driver is the person who writes the code while the Navigator observes and navigates each line of the code. Both developers can switch roles when needed.

Although the process may seem to slow down the development process, as having two heads increase the possibility of clashes or some developers work better and faster alone. However, we are actually investing in a lot of factors that maintain the code base’s health along with the code review program. Here are some of the benefits:

• Catch errors early on. There are two eyes that watch each line of code. This leads to better quality through a reduced number of defects and better instant analysis of programming decisions.
• Better knowledge transfer across the team. When you develop on your own, you are the only one who knows and understands the process, lessons, or possibly useful productivity tips and tricks. Because pair programming requires engineers to collaborate directly — whether in the same room or remotely — it is easier for them to learn new skills through hands-on experience. Based on their knowledge, experience, and learning styles, each person approaches certain aspects of codes in a unique way. When two engineers collaborate, they can discuss their differences and decide which approach is best or even devise a new one.
• Improve team building & communication skills. Pair programming allows team members to share information quickly, which reduces the likelihood of them keeping agendas hidden from one another. This also makes it easier for pair programmers to communicate. Again it’s important to note that, pair programming will only be effective if both programmers are actively contributing to the process. Pair programming should never be done in silence unless they are so perfectly in sync that nothing needs to be said. More often, it means that they are not sharing their thought processes, thus contradicting the aim of pair programming.

Conclusion

So, that’s how we maintain the health of our codebase. It might not be perfect but works quite well for us. Right now, we are in the process of implementing the Trunk-based Development (TBD) in our workflow, and there might be changes in how we the dev teams execute projects.

So, stay tuned for more information about our journey!

Are you also interested in tinkering with ways to maintain a healthy codebase? Then you’re already a Katalis (at heart). Join us!