I work hard in order to avoid work - My view on refactoring

Keff - Aug 30 '21 - - Dev Community

“I'm a pretty lazy person and am prepared to work quite hard in order to avoid work.” Martin Fowler

Now that represents me extremely well. I'm always striving towards working less 😝

For me one of the best tools for accomplishing that goal is refactoring. Not just refactoring but making refactoring a habit, and including that habit as part of my work.

What is refactoring?

I'm guessing that most of you already have a good understanding of what refactoring is, though I will explain in case you don't. This is what Wikipedia has to say:

"Refactoring is the process of restructuring existing code without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes) while preserving its functionality (more).

My take

I like Wikipedia's description, though it's missing an important concept, that in my opinion is one of the most important things about refactoring. And that's "TIME".

For me refactoring is a function of improvements over time (R = I/T). Refactoring will happen over time, iteration over iteration making improvements making sure nothing breaks along the way.

That's the reason why I made refactoring a habit, rather than something I only do once each couple of weeks or months. This has proven quite effective for me (emphasis on me, as I'm sure each one of you has their own way).

I also use refactoring intentionally as part of my development cycle, it is not limited to the daily habit or periodical refactors. It's usually at the end of the development cycle, after the initial, somewhat naive and probably not the cleanest solution. But the solution works, and makes me pass all the tests and meet all requirements.

After having a working solution I do a couple of refactoring passes, focusing on DX (Developer Experience) mostly, making code as clear and simple as possible.

What's my point?

My point is, that I've made refactoring a daily habit and it's working quite well. As developers, habits are one of the most important tools at our disposal, they can make sure we don't screw up, or making our life easier over time by enforcing good behaviours. But, habits can also be a bad thing, enforcing bad behaviours or ways of doing things (yes, I'm looking at you, the one who uses + to convert strings to numbers in js)...

For me, refactoring as a habit has been one of the most effective ways to work less. I started working hard, consistently improving the projects, and directing the efforts towards working less. As a side-effect the codebases become a pretty nice place to work and maintain.

I've been doing this for 4 years straight. These are some of the things I do:

  • Reorganize code to be as clear as possible
  • Rename stuff to make sense (hopefully, I'm crap at naming)
  • Extract parts of monster functions into separate functions
  • Keep related things together and unrelated things apart
  • Delete my colleagues' ugly code, and... cough... sorry, I mean, celebrate my colleagues' code, yes.
  • ...

Quite a short list, compared to all possible improvements.

Let me end it with another quote

This quote is from FunFunFunction's host Mattias, I think (please tell me if I'm wrong). It said something like this:

Remember to leave the code around you better than you found it

This quote stuck with me for some reason, I tried to apply it as often as I could, and after probably 4 years, it has become such a habit that I don't even realize I do it until I review my PR or something.

So yeah, maybe it works for you to. With this approach, the improvements and refactoring you do should be small, to reduce the amount of damage/side-effects (hopefully minimal if you do it correctly). Small changes each day of the week over 1 year amounts to quite a bit of improvement.

A short post from me this time, explaining really briefly my thoughts and approach to refactoring.

How do you feel about refactoring? Do you do it at all? And if so, what's your approach?

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .