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.
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
A major challenge of software development is that our work is by and large invisible. This makes our folklore essential in business matters. Some of our commonly used arguments and visualizations are digital urban legends rather than solid foundations for informed decisions. Here, we’ll go through a few examples and some measures to address our misconceptions.
How the stories we tell influence our decisions
When you embark on your cloud native journey there will be important choices to make about cloud providers, continuous deployment, environments’ setup and separation. This guide will help you make the right choices by sharing lessons learnt from running cloud native apps in production.
Kubernetes has become the de facto container orchestration platform. When we help clients of different sizes and domains start their cloud native journeys in Kubernetes, we assist them in making sound decisions and technology choices. There is no one-size-fits-all solution when it comes to choosing cloud providers, CI tools, continuous deployment pipelines etc., so it is important to make the right decisions at the start. Failing to do so can be very costly in terms of lost time and money.
How to make the right technical choices on your cloud native journey
Learn how Docker and Kubernetes work and the key benefits they bring. Using real demos, I show how Docker is a great packaging and distribution technology, and how Kubernetes provides a powerful runtime for containerized applications.
Watch this introduction to Docker and Kubernetes at the Trondheim Developer Conference (TDC)
In the world of Agile and DevOps we use many figures, charts and diagrams to argue and reason about our world and how we prioritize and make choices. However, at all levels of the organization, we misuse and misinterpret figures. It’s time to be explicit, measure the right things and act on them. Watch this talk from DevOpsDays Zurich in May 2019.
Watch this talk from DevOpsDays Zurich
Hear about upcoming events in Scandinavia, latest tech blogs, and training in the field of Continuous Delivery and DevOps