#begin

Refactoring

Refactoring, one of my favorite subjects since it always feels good to clean up the code. As your game evolves it will be necessary to clean up some junk you left behind. This is not necessarily about tech debt but simply has to do with the software evolving. Some parts were written without the full architecture in place yet, and when it is there, it must be integrated properly. Such scenarios happen all the time and are just part of the SDLC.

In the book they say that many people believe that software is like construction. An architect provides a plan, contractors put in the foundation and infrastructure like plumbing and electricity and build the rest of the house and then people can move in and live happily ever after. Haha, here is the waterfall mindset again. I think its really nice how David and Andrew keep on bashing on this.

They say that software is like gardening, its organic. You plant things according to the current conditions but as things evolve and the seasons go by you could start to restructure things. I for one need to move my olive tree closer to the house during winter or it will freeze to death.

But Andrew and David say that business people are comfortable with the metaphor of construction because its pretty predictable, scientific and repeatable. This creates a divide between the two parties and that’s exactly what the agile movement sought to fix. They failed miserably by the way. SCRUM for all its intends and purposes has probably made the divide greater. Why? Well because SCRUM was supposed to be a software development methodology with at its core the technical practices of eXtreme Programming. But it has evolved into a project management methodology. How many scrummasters do you know who have never read code and don’t have the slightest idea what Refactoring, TDD, Paired Programming, Simple Design and CI/CD even mean? I mean, they might have heard the terms but do they actually know what they mean? I bet, most do not since that’s not what they’re thought in their expensive 2 day scrummaster class. Sorry for the rant, let’s continue with the book. I wrote a blog about this about 3 years ago, you can check it out here.

When Should You Refactor

David and Andrew provide us with some reasons to refactor code. Reasons might involve, but are not limited to fixing duplication, Nonorthogonal design. Remember orthogonality? Orthogonal design means that things are decoupled and compartmentalized properly. Nonortogonal design means the spaghetti monster lives inside you steaming bowl of code. You should also refactor when the code was written with outdated knowledge. Software evolves, requirements change and you and your team’s knowledge of the problem and the domain increases. The code you write needs to keep up with these changes. And last, David and Andrew say that you can refactor code for performance reasons. Haha, yes you will probably do this many times over.

They say that refactoring is an exercise in pain management haha. I think that’s a great metaphor. Refactoring can be very, very painful since the code is always, almost working but now you need to torn it up. Many developers are still reluctant to ripping things up. Even when there’s a couple of hairs stuck in that bandage, get over it, rip it of and refactor and clean the code. In the end, things will be better.

Real-World Complications

A common problem with refactoring is of course that it takes time. Have you ever approached your superior telling him the code works but you need time to refactor? Well if they have some level of technical understanding they will comply with your offer. But most of the time they will tell you to, as Elon says: go fuck yourself!

Time is often used as an excuse not to refactor. But if you don’t refactor now, the burden will only increase and there will be an even bigger refactoring job tomorrow. The time investment will only grow. Uncle Bob is also very vocal about this. Never, ever ask anyone to refactor. It’s part of your job and you should refactor constantly. On the flip-side; Uncle Bob also recognizes that if your refactoring is going to take a considerable amount of time; you should put it on the schedule! You separate the refactoring in multiple smaller tasks and plan for them. We have discussed this multiple times on the show already but sometimes, in order to make a deadline you hack in some code to tie things together. But once it’s released and deployed you dive back in and clean up the mess. Your managers should understand that.

David and Andrew also say that refactoring should be done in a timely manner because the problems you’re trying to remove can spread. A common problem you will often see in Unity Apps is the dreaded singleton. If you see this as technical debt and you should refactor it, it could spread. Other members of you team might see this pattern, think it is OK to use singletons and all of the sudden your code is sprinkled with singleton magic. Messing up the orthogonality of your system, and testing of course. If you have a singleton in your code, you only ever need one…

How Do You Refactor?

So how exactly do you do refactorings. Haha, yes this is a point where the book shows its date of course. Current IDE’s have such strong refactoring tools that you simply cannot compare it to whatever crap developers had back then. David and Andrew mention that refactoring started out in the Smalltalk community. Smalltalk developers were so much ahead of their time, which is a talk on its own. Really, a legendary language.

But at the heart of refactoring is redesign. Redesign is always looming as new facts, deeper understandings and changing requirements are always coming. You need to be on top of things to not dig your own grave. The longer you might postpone some redesign, the worse the problem will get.

Refactoring is a delicate task since it’s really easy to break stuff. But luckily we have a suite of tests that will cover our backs while we do it. Would you dare to refactor, without your modern IDE and tests? I’m not so sure. For example; just renaming a variable could be problematic if you don’t have static analysis tools pointing out places that result in compiler errors. If you have tests, you simply run them and find out quickly.

In his book “Refactoring”, Martin Fowler gives 3 simple tips to refactor. 1: Don’t try to refactor and change or add functionality at the same time. 2: Make sure you have good tests before you begin refactoring. Run these tests as often as possible. That way you will know quickly if your chnages have broken anything. 3: Take short, deliberate steps: move a field from one class to another, fuse to similar methods into a superclass. Refactoring often involves making many localized changes that result in a larger-scale change. If you keep your steps small, and test after each step, you will avoid prolonged debugging.

I finally found a 1^st edition hard cover if this book on a second hand book store last week. Which is pretty awesome. I’ve read sections of it before but now I have the original 20 pound book. Yeah, that’s how heavy it is. You could probably through it through a window haha.

But refactoring sometimes spans architectural boundaries. When this is the case you should sync up releases and make sure you cover everything up the dependency graph. You prepare the necessary PR’s if you have access to these repositories of course. Else, you should coordinate with the other teams to proliferate the changes required to complete the refactoring and make it a success.

So next time you find a piece of code that’s not quite as good as it could be. Refactor it and refactor make sure the dependencies still line up correctly but up-and-downstream.

#end

01010010 01110101 01100010 01100101 01101110