Still relevant or increasingly redundant?
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.
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.
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”.
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”.
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.
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.
Do you have a tendency to use the backlog as an eternal placeholder? If so, you probably have a lot of clutter that’s creating a lot of frustrations for your end-users. In this post we’ll show you how to clean up your Jira issues and reduce the backlog with some basic JQL queries.
Tips to improve project management in the Atlassian suite
How to test Kubernetes artifacts like Helm charts and YAML manifests in your CI pipelines with a low-overhead, on-demand Kubernetes cluster deployed with KIND - Kubernetes in Docker.
Low overhead, on-demand Kubernetes clusters deployed on CI Workers Nodes with KIND
Had enough of sluggish polling? With instant Artifactory event triggers you can give responsiveness in Jenkins a real boost. Here’s an easy way to set it up.
A super easy configuration guide
In software development tight coupling is one of our biggest enemies. On the function level it makes our application hard to change and fragile. Unfortunately, tight coupling is like the entropy of software development, so we have always have to be working to reduce it.
How to safely introduce modular architecture to legacy software
I am an Atlassian certified trainer and over the years I have been spending much time with clients and their Jiras. In this blogpost, I have collected some small tips and tricks that will make your Jira usage better.
Jira Software is a powerful tool deployed in so many organizations, yet in day to day usage people are missing out on improvements, big and small.
In this post, I’ll take a closer look at the version of Jenkins X using Tekton, to give you an idea of how the general development, build, test, deploy flow looks like with Jenkins X. How does it feel to ship your code to production using a product coming from the Jenkins community that has very little Jenkins in it?
A crash course in Jenkins X and how to test it out on a local Kubernetes cluster
In this blog I will show you how to create snapshots of Persistent volumes in Kubernetes clusters and restore them again by only talking to the api server. This can be useful for either backups or when scaling stateful applications that need “startup data”.
Sneak peak at CSI Volume snapshotting Alpha feature
When I read Fowler’s new ‘Refactoring’ book I felt sure the example from the first chapter would make a good Code Kata. However, he didn’t include the code for the test cases. I can fix that!
Writing tests for ‘Theatrical Players’
Nicole Forsgren and the Accelerate DORA team has just released the newest iteration of the State of DevOps report. The report investigates what practices make us better at delivering valuable software to our users as measured by business outcomes. Read on for our analysis of the report, and how it can be best put to use.
The latest drivers of software delivery performance
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps