Refactoring in the Age of Microservices

With the arrival of microservices code is becoming disposable. Does this mean that we no longer need maintainable code? Is it the end of refactoring?

We live in a time of transition. For software developers it’s always like this because our field is young and we are constantly inventing new ways of building better software. I have been asked several times lately if microservices mean the death of refactoring, so in this post I will zoom in and take a close look. But first we need to examine how we got here.

Pre-refactoring: Design Patterns

In 1994 “design patterns” were state of the art software development practices. The book introducing this idea was so groundbreaking and widespread that it is still known by its nickname “The gang of four’s book” – due to its four authors; Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

The Gang of Four realized that many of the maintenance challenges software developers faced were similar. They realized that changing code by modifying it ran the risk of breaking existing functionality. A much safer way was to design our systems so we could make changes by adding new code.

The Gang of Four categorized many common situations where we could build in object oriented designs to enable change by addition. Fundamental to all of them was that object composition was preferred over inheritance. This is because composition enables change by addition instead of modification. If you only add it is hard to introduce errors into working code.

Refactoring

While design patterns are amazing if you have a green field project, they are not easily applicable to existing code bases. Refactoring was the answer to this.

Refactoring describes the process of improving code bases without changing their functionality. Mostly the focus was on readability, but a side effect of this is often maintainability. This shifted the focus from being on “what design patterns were” to “how do we get them into our code bases”.

Post-refactoring: Micro Services

In recent years the invention of microservices has pushed modularity even further. Microservices are about splitting our application into multiple smaller applications called services. These services have their own responsibilities and can be deployed separately.

The services are smaller than the large application. This means that individually they are easier to manage, faster to build and deploy, and if designed correctly can be added or removed while the system is running. There have been many discussions of how small ‘micro’ is in the context of services. I think it depends on the organization. My view is that a service is ‘micro’ if the organization is not afraid to throw it away and re-implement it from scratch. For some organizations that means “whatever a developer can do in 4 hours,” for others it might mean “2000 lines of code”.

The Death of Refactoring?

Code is becoming more and more disposable. As organizations become less afraid of simply deleting a microservice and starting over, the need for maintainability, and hence refactoring, disappears.

Great advantages come from this, such as the ability for developers to choose the programming language and tools they are most comfortable and effective with. The reason for having everyone use the same language is to ensure that everyone can maintain all the code. As is true for most things, our system benefits from diversity, especially in terms of resilience and flexibility.

The State and Future of Refactoring

Currently refactoring is an essential step in the process of moving from legacy systems to microservices. No matter what size our organization considers “micro”, we still want to maximize how much we can do in that time. We believe that refactoring is an excellent tool for teaching and practicing coding skills.

Refactoring is a specialized tool, both for transitioning between software architectures, but just as much for learning. Learning refactoring makes developers more productive, even if they are not doing refactoring as part of their regular work.

This is what Technical Agile Coaching is about. It makes developers more productive through established DevOps practices, particularly design patterns, refactoring, software architecture, automated testing, and pair and mob programming, to name just a few.