DEV Community

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

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

Keff on August 30, 2021

“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 a...
Collapse
 
dgpickett profile image
David G. Pickett

A good programmer is a dialectic tension between OCD and lazy. Take care of every detail, but do not make details you do not need!

However, procedures and loops that do not fit on the screen are hard to diagnose. Pushing hunks of related details into a subroutine solves that, and allows individualized subroutine testing, which avoids debugging/supporting a huge procedure or loop! It's not much work. It protects you and future maintainers (if your code lives through the ages, which would be amazing) from lots of work!

Collapse
 
ldrscke profile image
Christian Ledermann

Code is suprisingly longlived ;-)

Collapse
 
bashbunni profile image
bashbunni

100% this

Collapse
 
miketalbot profile image
Mike Talbot ⭐

I definitely agree with little and often refactoring - BUT - I also think there are times to take the 50,000ft view and say I could do a major thing here - and do some very serious moving around of stuff perhaps to make things more obvious.

My day job is building a ThingBuilder - a builder of things with literally 100s of plugins etc and quite a few devs. We recently completely restructured the code base for our plugins and after I am so happy, I must save minutes every hour finding the right code section now. We also refactored all of our file names into a new convention which is much easier to find in WebStorm search everywhere. Of course if you move a lot you'll need good tests :)

Collapse
 
nombrekeff profile image
Keff

Totally agree, as I mentioned in the post I also do refactoring periodically and from time to time I tackle major things that can't be done with the litle and often approach.

We recently completely restructured the code base for our plugins and after I am so happy, I must save minutes every hour finding the right code section now

That's always such a good feeling, and can relate quite a bit. As we recently re-wrote an app I was put in charge of, it was so bad we had to re-write it from scratch, no room for refactoring there. Working on that project now is so much nicer, easier to maintain, etc... I enforce refactoring on the project and don't allow the "I will do that later" syndrome that @inhuofficial pointed out!

And of course we do have tests, not the best but quite good :)

Collapse
 
honatas profile image
Jonatas de Moraes Junior

Refactoring is an art, as much as programming itself. If you do it wrong though, you will be changing the code for worse. That's why most managers hate that word - its a lot of time spent with no gain whatsoever.

However, when done correctly, not only it saves money (because time is money and refactored code takes less time to mantain), it also makes the devs happier because the work gets done easier and this ends up saving even more money.

I believe refactoring should be part of the daily dev routine, but taken with a grain of salt. Learn the technicques and understand the true reasoning for it, or else you will just be wasting time.

Collapse
 
nombrekeff profile image
Keff

Yeah I totally agree. As many things in life, if done incorrectly or without knowledge, can result in bad outcomes.

I also think good refactoring skills go side by side with your coding ones, like any other skill it's gained over time and practice. So we should try, as managers or not managers, to not hate on it and try to teach it better 😅

Thanks for the addition!

Collapse
 
grahamthedev profile image
GrahamTheDev

Little and often is an old saying, or if you are a chef “clean as you go”.

The “I will clean it up later” syndrome has cost me a lot of money over the years in having to unravel what i wrote years ago. Keep on top of it and it is easy!

Great article with a very important message ❤️🦄

Collapse
 
nombrekeff profile image
Keff

Thanks, I too believe it's quite important.

My company too, has lost loads of time and money for this very reason. Just as an example, we had a project that at one point scored around 3.5 years of tech-debt, when the project was around 1.5 years old 😂. The reason? Saying “I will clean it up later” (if they even thought that) and not coming back and cleaning.

Collapse
 
evgenyk profile image
Evgeny • Edited

My experience is that amount of refactoring is inversely proportional to the amount of people working on the code base and directly proportional to the freshness of the code.

In other words, I refactor so much more the fresh code to make it as good as I can, as I know for sure that other devs wouldn't be resolving conflicts as a result of my refactoring. On the other hand, the more people are working on the shared code, more "differently" old branches the code base has, the more chances that even the smallest refactoring could lead to other developer's pain, or maintenance pain, or production pain. I tend not to refactor as much in that case, or rather prefer the approach of write new and replace, as bigger chunks are easier to resolve than a conflict spaghetti.

To me the refactoring is a delicate balance between empathy to other developers, freshness of the code and the size of the team.

With large teams it is better not to refactor much if you want to keep delivering usable software, hence over time the codebase begins to smell like a pile of turd.

Collapse
 
nombrekeff profile image
Keff

I like this one, and can relate.

I work in many projects, some small, some big and some personal. And yeah, it's a lot easier when you're alone or in rather small and new projects. But I think it's important to do it in such projects, as to make them be in the best shape possible before it becomes a big project or many people start working on it. As later on it's harder to do as you mentioned.

hence over time the codebase begins to smell like a pile of turd

I have a couple of those at our company, they smell from 5 miles away lol

Collapse
 
rusimovmilan profile image
Milan Rusimov

I agree with you Keff.
Refactoring is one of the most important things, actually a gift that one developer can give to himself.
It doesn't save just your money and time, it's also one of the best ways to learn more efficient about what you are doing.
Refactoring is actually a life's thing.
It should be a part of everybody's life, not just codding.
As Ray Dalio said: "Pain + Reflection = Progress"(youtube.com/watch?v=i4wXCv4GLU0), and yes, reflection in life is refactoring in development.
As Steve Jobs said: "You can't connect the dots looking forward; you can only connect them looking backwards."(brainyquote.com/quotes/steve_jobs_...), and yes, looking backwards is actualy a reflection (refactoring).
Encouraging everyone to do it.

Collapse
 
joancomasfdz profile image
Joan Comas Fernandez • Edited

I usually try to avoid words like "clean" or "clear", even "understandable". Although there are books written about it, they are quite subjective.

Instead I speak about "explicitness", "expressiveness", "no surprises", etc.

I also try to keep a mental track of how much time I need to understand some code, for example from stack overflow, and i put that in a balance with writing a less smart code that requires less time to understand. And therefore less comments.

Collapse
 
nombrekeff profile image
Keff

Interesting point of view. I kinda agree, and I like the words you use though they express mostly the same thing.

But I'd say that yes it is subjective, as almost anything in life. But many of the "clean" code guidelines are quite objective, like cyclomatic comlexity, separation of concerns, keeping functions and methods small, just to name a few. These have proben quite efective in reducing the complexity and increasign what you call "expressiveness" and also reducing surprises.

I'd also like to add my grain of salt to the comments thing. It might be controversial, but I hate comments in code (speaking of comments explaining a piece of code, public apis should always be commented and documented), they add an unnecesary layer of complexity and one that needs maintaing like other parts of the codebase. Code should be readable/understandable by itself, comments should not be needed (most times) to explain how the code works, the code should be expressive.

Every time you write a comment, you should grimace and feel the failure of your ability of expression.
Robert C. Martin

Collapse
 
joancomasfdz profile image
Joan Comas Fernandez

Yes I totally agree with you on the comments! And that is totally my point: avoid comments with less smarter and more expressive code!

Its just that... Have you ever worked with a developer who will twist and bend the rules? Or just focus on 1 rule (usually code duplication)? Of course cyclomatic complexity is hard to bend, but out of the multiple rules in the Clean Code, a fair amount of devs I worked with knew just a few and applied them in a questionable way.

So I had to adapt :)

Collapse
 
petermortensen profile image
Peter Mortensen

The main use for refactoring is not to improve bad code, but to reduce/eliminate redundant code.

Redundant code is often the result of copy-paste reuse (the worst kind of reuse), for very short-term gains. Instead of functional abstraction, code is copy-pasted and slightly changed, building up technical debt that can slow development to a crawl, often 10 times slower or worse.

Collapse
 
nombrekeff profile image
Keff

Yup, I totally agree. I have seen that kind of technical debt, a project of ours which was done in a copy-paste way without much thought, ended up with a tech-debt so big it would've taken us 2.5-3 years to remove. This project was 1 year old at the time

Collapse
 
danieljsummers profile image
Daniel J. Summers

If you compare technical debt to your credit card bill, you are making your monthly payments, plus a little. That is a wise and entirely-reasonable thing to do, IMO.

(Granted, paying the whole thing off every month is the best; but, if you can't, this will get you there much more quickly than if you just did the bare minimum.)

Collapse
 
moopet profile image
Ben Sinclair

I generally agree.

But I'll point out that there are a lot of us who work on quirky foreign systems and codebases without much if anything in the way of testing. It's very easy to slip in a new bug when refactoring, and unless you have good tests for before/after, you might end up doing more harm than good.

I know, I know, that's a terrible point of view. But it's the practical one sometimes.

Collapse
 
nombrekeff profile image
Keff

Yeah, good point. I've had a couple of those 😅

I agree, because although there are some ways of refactoring that reduce the possibilities of harmig the system, it will never be totally safe. I would say that having tests gives you a lot more freedom and safety to refactor (but tests must be done correclty)

Collapse
 
monfernape profile image
Usman Khalil

It's writings like this I search for where developers share their views. With that said, I try refactoring the code that seems off to me or at least what I think can be made better

Collapse
 
nombrekeff profile image
Keff

Thanks for that! I'm glad you enjoyed it, I did enjoy writing about it 😊

And yeah, you should not refactor code that does not need to be refactored. But here will always be some weird or ugly code that could benefit from a good ol' refactor!

Collapse
 
rnkrnk profile image
RN • Edited

yes, I'm looking at you, the one who uses + to convert strings to numbers in js

What's wrong with unary plus? I googled it and found out that some people think "it has poor readability", "it could be easy to miss". It seems to me that if a developer "misses" characters, the problem is his poor concentration, and he should be more careful in his work. I doubt that the code will become "easy to read" if we replace all single-character operators with words like "plus", "minus", "multiply", "percentage", etc.

Collapse
 
nombrekeff profile image
Keff

There's nothing wrong in using it, and yeah I agree in part. But you can't expect developers to be 100% concentrated and careful 100% of the time, we're humans and as humans we might have a bad day, we might have not slept well, etc... A new developer might not yet know how the unary operator work, it's not intuitive at all. You already need a good knowledge of the language.

So if I have the choice I will use other options before the unary operator to convert strings to numbers. This way we reduce the possibilities of a miss. And I usually prefer to make my code literal, ie using Number('1') or parseInt('1') instead of +1. It might be a personal preference, but I really think it can be beneficial to not use it if it can be omitted.