Explaining Refactoring: Better Code at Lower Cost

Today we're going to talk about one of the most important elements within the software lifecycle: performing refactorings.

1 - What is refactoring?

Refactoring is nothing more than the process of changing the internal code of an application without altering its external behavior; in other words, with the same inputs, we get the same outputs.

2 - Why should we refactor?

We shouldn't refactor code just for the sake of refactoring; the main goal is to make the code cleaner and easier to maintain.

Of course, we may have other goals, such as improving performance or reducing costs, which, in real production environments, are often the main reasons.

To give you a clear example of this point, imagine you had an endpoint in an API which received 10 calls per minute. For some reason, your application becomes popular and sells more, and now it gets 1000 calls per minute. Suddenly, that endpoint is much slower than before.

One solution here is to assign more resources to the machine running the application. Generally, this works, but at some point, keeping the app running could cost thousands of euros per month. That's when refactoring the code comes in.

As you investigate, you realize that your microservice receives all products (only the ID) from a shopping cart and then queries the products microservice one by one. With 10 calls per minute, this wasn't an issue, but with 1000, it definitely is:

If you look closely, this is just for each call to our service, which means that every call results in three calls to the other microservice. With 10 calls per minute, we make 30; with 1000, that's 3000.

Depending on how you've implemented the solution, you might not have enough threads, so some calls will wait. In other words, you could run into thread pool starvation as we discussed in another post.

A possible refactoring solution here is to change the for loop that queries products one by one to a single call that fetches all products at once from the products microservice.

Obviously, you have to update the products microservice to expose an endpoint that can handle this call and update your code to use this new endpoint.

While the change might seem minor, it's not: we're reducing the load on two microservices and on the network, since by changing many HTTP calls to a single one, we establish just one HTTP connection between the applications.

3 - When and how to refactor?

Ideally, we would say that we should always refactor, but that's not realistic, especially in a business setting where value must be delivered to the company.

Something to keep in mind is that refactoring doesn't change the input or output, so it's hard to convince higher-ups to refactor a live production project, especially if they lack technical knowledge. To them, if it works, it works. They don't care if it runs on the latest version of .NET or .NET Framework 1.0.

When a project is already in production, a good reason to refactor is to cut down running costs. If our app costs €2000 a month and, after analysis, we see it could cost €100 a month, refactoring may be worth it, depending on how long it will take.

This is similar to migrations; depending on the type of migration, you might end up with a lot of duplicate code or dead code (unused after migration). The best approach is to plan and create tasks around this, as they're likely to get approved. But if, at the end, you say "we could change this and this and this," it'll probably never happen.

We also have cases where refactoring is needed during development. Common scenarios are using variable names that make sense or breaking down long classes or methods that do too many things, restructuring them where possible.

The main idea behind this kind of refactoring is to improve future code maintainability.

4 - Refactoring my blog

Refactoring, in the end, is just a part of the software lifecycle; you know I like to present everything with real use cases, and for this scenario we have my blog.

The current state of my blog is the one I created about five years ago, and my way of seeing and understanding software has changed since then.

In this refactoring, I'm going to change two elements:

4.1 - Refactoring the structure

Back then, I created the blog application using the structure we saw in the post "application structure". And while I think it's a good structure because it separates layers very elegantly, when you're a solo developer aiming to deliver as many features as possible, it's not always ideal.

The image on the left is a screenshot of my own backend, where you can clearly see that we could compress the services layer and the servicesDependencies layer into one.

The serviceDependencies layer is the one responsible for talking to the database or the mail system to send emails with the book "Complete Full Stack Development Guide with .NET" when a successful payment is made.

As I said, in a company with employees, it might make sense to have this separation, but at home, by myself, it only increases my workload.

4.2 - Migrating from Dapper to Entity Framework Core

The second part is the database. Five years ago, I decided to use Dapper instead of Entity Framework Core. That choice worked well at first, but in the latest .NET versions, Entity Framework has improved a lot. Because of its simplicity, that's what I'm going to implement. I like Dapper, and honestly, it works very well for me, but writing queries manually tires me out a bit. While this change isn't strictly necessary, I think the time has come.

For those interested, I'm going to use a Database First approach during the migration, since the database is already made.

Both changes will allow for faster development, which is what matters.

4.3 - How to approach refactoring

I've spent two years thinking about changing this structure, and for lack of time, I haven't done it. I think the time has come. However, it won't be a big bang, I will take it slow. Migrating to Entity Framework isn't much of a mystery; I just need to create the DBcontext and the models will be created by the designer automatically (more info in the post about database first).

Both my current implementation and the inclusion of the DbContext can run in parallel, which is what I'll do for now.

For the migration of use cases/scenarios/services, call it what you like, I'm going to do something similar. I'll work with the new and old versions at the same time. The difference is that I'll create a new project called "Workflows" and put the new implementations there.

This will allow me to migrate scenarios one by one without needing to do everything at once.

In reality, I may not migrate anything or migrate very, very slowly. The usual approach is: if you don't have to touch it, you don't migrate it. But if you need to make a change, you take the opportunity to migrate that section.

That said, everything new I create will go in the use case layer, and dependencies such as the database or mail server will be injected into that use case, done.

In the end, what I'm looking for is greater speed when developing and releasing features.