Many developers want to "rewrite the whole application" and "get rid of all that sh*t". Most of them are pretty blank when I tell them that I really like working on such code bases, even if I just jumped into the code. I recently talked about that to the other Qafoo members and all of them agreed to my views. Therefore I want to explain our love of legacy code in this post. Email not displaying correctly?
View it in your browser.
Qafoo Newsletter – 04. Apr 2017

Hi %recipient.name%,

This is Toby and I got news from Qafoo for you – as always you get some new insights and we hope you enjoy it. If you have ideas what you want to read about or other improvements just drop us a mail.

Read & comment newsletter in our blog.

Toby

Loving Legacy Code

Many developers want to "rewrite the whole application" and "get rid of all that sh*t". Most of them are pretty blank when I tell them that I really like working on such code bases, even if I just jumped into the code. I recently talked about that to the other Qafoo members and all of them agreed to my views. Therefore I want to explain our love of legacy code in this post.

The first thing to realize about existing code bases - no matter how bad you feel their quality is - is that it provides business value. The code is in production and people use it and gain value from that. For us as developers that means: The business rules that the appplication is meant to reflect are already written down in code. There is no need to discuss the purpose, how things are meant to work and which goals should be achieved. We already have a machine readable version of the business vision and it works. One of the biggest issues in software development has already been taken from our shoulders: Understanding the business and implementing a solution accordingly.

When implementing a new program on the green field you have a high amount of uncertainty about the eventual goals. Extracting and documenting requirements is a tough part for all stakeholders and many iterations need to happen before we even reach the stage where software is usable and production ready. Which applications that have grown throughout years these steps have already been done. As developers we can read the eventual decisions how the software should work: It is already there, written down in a language we can naturally understand: Code!

Even better we also know what are common change and extension points and use the technical patterns which are optimal for the change we saw in a couple of years. Developers are often wrong when anticipating change, but in this case we can analyze the past development and have data to base on when anticipating change.

Now we "only" need to move around the code so that its functionality does not change but that we can better maintain it and get rid of technical dept. Of course this is not a picnic, too. But instead of tackling on an additional layer of complexity we can focus on refactoring. If we created a good refactoring basis already, we can even perform that task on the go beside implementing new features and fixing bugs.

Qafoo experts can kick-start your team with a continuous refactoring process. We can show you how to improve your source code quality on the go and help you to get rid of the big quality chuckholes in your construction site.

I could even go that far to tell you that implementing software on the green field is rather boring for me. Of course there are always smaller parts which are interesting and challenging but most tasks are just boring. It's different with unknown legacy code bases. You need to be creative to apply at least a minimal amount of testing before you can start to refactor. You need to follow the minds of multiple developers of which some even might not be in sight anymore. You need to understand what patterns are realized in a software, what would improve the code quality and find ways to reach that goal without disturbing every day work. This is the interesting stuff. :)

In legacy software you can let technical patterns emerge for a proven domain.

Tobias Schlitt

You can read more about refactoring approaches which can help you in our posts on Extract Methods and Extract Services.

Crafting Quality Software

As a newsletter subcriber you can download our book Crafting Quality Software – Gems From The Qafoo Blog any time. The book is a curated collection of blog posts from the Qafoo Team Blog. Over the time we created many blog posts focussing on the topics of Clean Code, Object Oriented Design, Testing, Refactoring and Software Architecture.

You can also buy a printed version of the book on Amazon or on epubli.

The Book

Crafting Quality Software – Gems From The Qafoo Blog

Related Articles

Find some related articles which might be of interest for you…

Refactoring Should not Only be a Ticket

24. January, 2017

In this blog post I would like to elaborate a bit further on why refactoring should never only be a dedicated task on your board. It should be an essential part of every task you work on…

Read more…

Learn OOD - to unlearn it again

11. February, 2014

One topic we regularly teach in workshops for our customers is object oriented design (ODD), i.e. the art of crafting classes/interfaces in a way that the result is an easy-to-understand, maintainable and flexible code base. With the agile focus on shipping working software, some might consider the skill of OOD less important. One popular argument is that quick reaction to change is more important than designing objects and their interaction carefully. I personally look at it the exact other way around. This blog post summarizes why you need to learn OOD first, in order to avoid it to some degree again.

Read more…

How to Perform Extract Service Refactoring When You Don't Have Tests

21. March, 2017

When you are refactoring in a legacy codebase, the goal is often to reduce complexity or separate concerns from classes, methods and functions that do too much work themselves. Primary candidates for refactoring are often controller classes or use-case oriented service classes (such as a UserService). Extracting new service classes is one popular refactoring to separate concerns, but without tests it is dangerous because there are many ways to break your original code – we show you how this can still be done.

Read more…

Basic Refactoring Techniques: Extract Method

07. March, 2017

Refactoring is the process of restructuring code without changing its behaviour and the technique "Extract Method" is one of the most important building blocks of refactoring. What do you need to keep in mind while doing this?

Read more…

Follow on Twitter   Friend on Facebook Contact    Weblog    Imprint    News
Copyright © 2017 Qafoo GmbH, All rights reserved.
Get in touch: contact@qafoo.com
Unsubscribe from this newsletter