Compromising code quality for faster release? Bad idea
Too many times we have heard tales of code quality being kept on the back burner for the sake of a Monday morning release and then never ever picked back up, let’s explore why is this a bad idea.
Hello everyone. I have been working on the Trell Gamification engine for more than two months. Our team has delivered more than three releases in this time with many features, integration of various distributed systems, and cron jobs. We delivered all the features well up and running beforehand for testing purposes and, last-minute changes could be incorporated well in time.
Everything mentioned above gets done. But, at what cost? By writing ugly code. You heard it right. We compromised code quality to deliver all the features within tight deadlines to meet. But now, we are heavily focusing on refactoring our codebase. But, you would be thinking, why are we doing this when all the things are being done in time.
But why are we doing this when everything is fine?
Improve developer experience and ease of programming 🧑🏾💻
It becomes easier for us to understand code because more concise code patterns are being followed in our project and reduced duplicate code blocks. It results in high readability of the code, better understanding for developers that further results in higher productivity of the team for implementing new features from the root and updating existing one’s easily without any hassle in lesser time and lesser engineering hours.
A better understanding of logic 🤔
Structured code helps us in understanding the core logic of all the functionalities. It helps respond to all the questions related to the product that we are developing here and easily take on new tech developments.
Easily doing RCA of bugs 🐛
Doing root cause analysis becomes very easy. From my experience, I was able to spot around two to three bugs in minimal time after implementing refactoring that was previously taking minutes to hours to spot out. It was possible because duplicated logic was not absent and pure logic was present that made debugging of the code very easy and made life simpler.
Becomes easy to add new features 🆕
Trell gamification engine is a new feature. It is under development and, new developments are coming all along. Adding new milestones is much easier now, as all the steps with similar logic get abstracted. Only the development of the core logic of the new milestones takes engineering hours.
Becoming a better developer 📚
Thinking about various methods to improve our code leads to a better approach to modern coding problems, scenarios, and the ability to approach a problem in multiple ways.
As some great programmer once said :- “When you find you have to add a feature to a program, and the program’s code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature.”
I’ll share some examples below that I am at liberty to share with you which are not a part of core business logic.
Case Study 1: Improvising database calls
We don’t query the data from the database directly. To improve our error monitoring and find the root cause for any bug occurring we use Sentry. It provides various metrics and time duration for specified spans.
Currently, we use the below style for placing DB queries and making sentry spans. Over time it becomes a repetitive process. As you can see from the above sentry monitor, we are making over ten calls to the database in the initial stage of implementation of this API. I thought of improving the code style first by refactoring it and then implementing the code part for the main logic of the API.
Added some of the following helper functions that provide functionality for placing read queries through reader database connection and generating the corresponding sentry monitoring span and similarly for executing write queries through writer database connection with sentry integration.
Below is the new style for placing DB queries and making sentry spans. It takes less space, reduces repetition, and is easier to understand.
Case study 2: Improvising Cron Job monitoring
We have developed around four cron jobs, and we use healthcheck.io for monitoring cron-jobs. So, we need to place some HTTP requests from our cron job that updates the status in the Dashboard. In the start, we had the following structure in our cron jobs.
It also became repetitive over time. So, we put all the logic to form the URL directly in the function based on the cron job, and a method th5t stands for the state of the cron job (start, successfully finish, failure) and then place the HTTP request.
Impact
Implementing these has resulted in code reduction of about 17%- 22% in API’s handler code and about 25% in Cron Jobs and has increased the readability of code. Goal Achieved. Time to celebrate.
Disclaimer
If new changes brought by the product team are constantly leading you to change your code style. Then investing time and workers in refactoring is not worth it. Implement refactoring on those things which are not going to be changed or removed in the longer run.
Will come soon with another blog post. Bye 👋👋👋👋.
