Considerations For Refactoring

January 16, 2020 - Jake Bresnehan

Refactoring code is a great opportunity and a task that shouldn’t be taken lightly from my experience. Very rarely will you get a second chance, especially if you are doing the refactor for a client or your current employer.

Below I recap some thoughts from my experiences over the last 10+ years of developing, that will hopefully help you to become a little mindful before you take on your next refactoring project. I don’t dive into how to refactor languages. Rather, I take a look at the mindset before diving in, to make it a better experience.

Refactoring isn’t fun, it can be boring, lonely and often stressful. Saying that, it can, on the other hand, be very rewarding and a great experience.

Typically, the lifecycle of refactoring goes something like this:

  • OMG, let’s refactor X.
  • Convince your boss over many months that they should make this a priority for the business. Continue to hound them until you get the go-ahead.
  • The first week, you are so excited and you work your butt off. The world is great!
  • The second week, you start to question yourself why the hell you decided to do this. Every section of the codebase you tackle is overwhelming.
  • The third week, you are hating your job and there is no end in sight. The budget for the refactor is small so you are the only one working on it (generally what happens from my experience). It’s lonely.
  • The fourth week, your boss starts to hound you, you get stressed and start to freak out. The code you are rewriting is becoming rushed and you aren’t as happy with your output as you envisaged.
  • The fifth week you dread opening your computer… You can’t see the light at the end of the tunnel.

Refactoring can be a strange process but with some good forward-thinking, blood, sweat and tears it can be a great opportunity to help, not only the business, but customers and developers involved in the project going forward.

Five things to be mindful of before and during your next refactor project:

  • It’s our job. That might sound pretty harsh, but, at the end of the day, refactoring is needed. We learn, we grow and business logic expands. It can be dirty work. It can be boring. It can be challenging. In these times, try and think of the positives.
  • More often than not, it is a lonely experience. I can’t remember the last time I did a refactor project that involved more than 2 people. Most of the time, it has just been me. Make sure you stay sane, communicate and bounce ideas off your fellow team members.
  • The last 10% of a refactoring project seems to take forever and is one of the most important times to make sure it continues on the correct path. Generally speaking, you’ll be totally over it by this stage, but stay on track. Don’t waste all the hard work you have done.
  • Not all refactoring projects are successful. Make sure you reflect whatever the outcome and take that knowledge into your next refactor project.
  • When the shit hits the fan, think on the bright side. Use it as an opportunity to show off your skills, level up and prove to yourself you are a good developer. Not something that is easy, but it will be rewarding.

Hopefully the above has given you a few takeaways to make your next refactoring project a successful endeavour. Refactoring isn’t the most glamorous part of developing, but it’s a rewarding process and a great opportunity to grow, learn and feel good about your work. Maybe next time you are in a planning meeting when someone talks about refactoring, be the person that puts up your hand and be the change you seek.