Digital Expert Skills

Why refactoring is actually fun! (3-4 min read)

Introduction

Let’s start by stating the obvious. Just to get it out of the way. Refactoring is a necessity. There is no way around it. When you’re developing a sustainable codebase that is of reasonable size there will be moments where you get confused or find duplicate code, somewhere. Stuff will end up in the wrong place while you’re focusing on problem solving which is not weird at all. It’s just something you have to be aware of.

Design Patterns

Even if you are a strong believer in design patterns and manage to stick to them very consistently there is still danger in writing functions/classes that are too long and should be broken up into pieces. When thinking about solving a problem it is sometimes hard to think about splitting and dividing up parts of your solution in order to make every aspect as reusable as possible. Especially when the structure isn’t 100% clean in the first place. You quickly start copying code into your domain to see if a certain idea you have actually works. I think we have all been there.

Patterns are also somewhat interpretable. There isn’t always a clear line where certain logic should be written. It is good practice to review your choices from time to time.

Growing your dev team

These facts gets intensified greatly when you consider other people fumbling around in your codebase. If the pattern or structure only makes sense to you, it’s not very expandable. Expandability is the main goal of owning and managing a sustainable software project.

It’s best practice to keep some made-up junior dev in mind when laying out your big lines of code. If you can’t onboard him/her into your project in less than <fill in your limit here> hours you should reconsider the choices you have made.

Ensuring other members of your team stick to these rules and regulations isn’t always straight forward either. It gets incredibly hard and time consuming reviewing each line of code in each pull request for each member of your team. That is where agile methodology can assist. Keeping the pull requests very small can allow you to read through them a lot easier. Not focusing on each line of code but morereading the flow and structure.

Don’t read what is written but focus on how it is written. This will speed things up immensely and honestly, no one likes micro management. If the tests pass and the code is well structured, the pull requests should be approved. However, there is a very fine line to be walked here. “The code is well structured” is somewhat subjective. It has to be someone’s responsibility to keep an eye on this and to define what ‘well structure’ actually means.

Time to refactor

When you start refactoring, (or have to start refactoring – for any procrastinators reading this), the hard work is done. The problem you set out to solve has been solved. Please stick to this. There is no point in refactoring while you’re still problem solving. It’s like cleaning the kitchen while you’re cooking. It is not efficient.

During problem solving, solving your problem should be your only goal and focus. Refactoring, whilst important, comes after. Of course it can be somewhat combined and certain rules of clean code can and should be taken into account while coding anything. But usually it’s easiest and most efficient to just make something and clean up after. To get back to the cooking analogy, obviously when cutting up vegetables you throw the unused bits in the trash before moving to the next step of the recipe but don’t start scrubbing the floor after every carrot you peel.

So, back to topic. The hard stuff is done, the problem is solved, all tests pass, life is great. Honestly at this point you deserve a break. Go take a 5 minute walk, make some tea or whatever, destress for a little. Get ready to review your own code. I have a soft rule that I drink coffee for poblem solving and tea for refactoring. It sets the mood I am about to describe perfectly.

Why refactoring is awesome

Problem solving is a time of great complexity and focus. You’re trying to solve something that hasn’t been solved before, or at least not in your codebase. It’s a hard process that requires coffee and your undistracted attention.

Refactoring on the other hand is a time of joy. It’s a time of reading your own clever solutions and thinking about how smart you are. Being proud of your work. Reading it over and spotting things to make it even better is awesome. Trust me. It’s your chance to impress your colleagues and peers even more. Discovering the solution is one thing, but packaging it neatly and delivering a finished product is what you should strive for.

Reviewing your own code is very important. You learn a lot more about your problem and your solution. This is a great time to document your code. Truly understanding your solution allows you to share that knowledge a lot better. It’s also a good way to spot possible bugs that the tests might not have covered.

Programming is kind of like writing a book. Authors read their own book an unbelievable number of times. Constantly rewriting and restructuring it. I believe programmers should take a similar approach. Constantly reviewing their own work in a very critical manner.

In the end, us programmers also write beautiful stories to be read and enjoyed by other developers. Always keep your audience in mind.

(The end-user gets to see the movie :p)

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *