DEV Community

Don't refactor the code

Paweł Świątkowski on June 13, 2024

This is a piece of advice someone gave me a long time ago. Unfortunately, I don't really remember who, so I cannot properly attribute (although cha...
Collapse
 
jmccabe profile image
John McCabe • Edited

Basically, all you're saying is never claim to be just refactoring code. The only reason you should be refactoring anything is because there's a clear, probably documented (e.g. bug report, feature request - including improvement) need for it. If you're daft enough to suggest that all you were did was refactoring, rather than "progressing with task x, which needed some existing code to be refactored", then you need to think harder about what your actual end goal is. This is what you're saying; the headline of this article is, however, provocative and untrue.

Collapse
 
seisgasse_house1_8aff1d2a profile image
Seisgasse House1

the title is stupid tbh. what the heck with these titles.

Collapse
 
bernardigiri profile image
Bernard Igiri

If no clicks then you're writing for nothing.

Thread Thread
 
seisgasse_house1_8aff1d2a profile image
Seisgasse House1

Then stop writing. Software Engineer is a science not a melodrama.

Thread Thread
 
tacodes profile image
tacodes

When you fix human nature, Seisgasse, you let us know! Until then article titles will be click-baity. Waiting on you!

Collapse
 
mahmoud_kanbar profile image
Mahmoud Kanbar

The title is so catchy, and give you a big rush to read the article, specially because you want to argue with the writer. "The content is the contrast of the title".

Very nice point of view, And I totally agree with you.

Thanks.

Collapse
 
bjmckenz profile image
Bruce McKenzie

I'm ok with the provocative title.

You are largely correct.

My only quibble is that i don't think of your reasons as truly refactoring. Improving performance? Not requiring. Should be product-driven. Testability? Should be qa-driven either specifically or in support of organizations goals.

Refactoring (to me) if changing the code without changing the functionality (including most non-functional requirements).

I think there are two reasons to refactor: "you have a change you are working towards and the code is not structured to make it clean", and "you are reducing technical debt" .

The former? You're writing on the change. You shouldn't check in those changes if you don't check in the feature.

What is technical debt? Things we now know we should have done differently. (Insert longer and more precise explanation)

I don't believe in "making it more open to GENERAL change" because that is not relevant to prodic needs. Is relevant as to our guess about product needs, and as such can be wrong, or a poor allocation of resources.

Keep up the clear writing!

Collapse
 
efpage profile image
Eckehard

If you tell somebody, you need time to clean up your room, isn´t this enough? Often it is not too interesting if you need the time to remove all the empty pizza boxes from your bed or if you are cleaning the windows.

Collapse
 
katafrakt profile image
Paweł Świątkowski

It is, if you are the only person using the room. Thing is, you are not.

Collapse
 
yutamago profile image
Yutamago

If it's a shared room, the other users might ask you why you cleaned up the room. Why you moved the closets to a different corner and why you relabeled the drawers. It was perfectly fine before.

Collapse
 
cmcnicholas profile image
Craig McNicholas

I agree, just saying "refactoring" is like saying I'm "documenting" or "compiling". Compiling or documenting what exactly?

It's fine to use the word refactoring but as you state it needs context, what is the goal trying to be achieved? Everything from better readability in a highly shared codebase through to renaming to follow conventions etc. are all valid reasons but you gotta be able to back up why else it's just busy work.

Collapse
 
pkubik profile image
Paweł Kubik

I agree. You need to stay focused on the real problems and proper reporting is an good way to promote that. It's not as much about reporting itself as about making sure that each contributor thinks about your goals. W sometimes find ourselves replacing if-else blocks with cleaner polymorphic interfaces, that we need to scrap few weeks later when they don't match some new features. Code quality can be easily misjudged when taken out of context.

That said, I think the sentiment of the title is a bit misleading and potentially harmful. Thinking how to report your work has a lot of benefits, but maintaining proper refactoring culture is way more important. I'd put quotes around "refactoring" in the title to better match your point.

Collapse
 
brense profile image
Rense Bakker

Yes and no. Sometimes it's not that interesting to go into details about what you refactored exactly. For example if you renamed some variables, that's not super useful to know. People who are interested can look at your PR and ask for clarification if they want more explanation. The reason why it needed refactoring could be important if the bad code could have been prevented beforehand.

Collapse
 
gunslingor profile image
gunslingor

Technically your right and I agree with the point, but is disagree there is danger in using the word if it is understood by the team... which unfortunately is rarely.

All editing is technically refactoring, so you have:

  • refactoring for features
  • refactoring for migration or obsolescence
  • refactoring for reorgization
  • refactoring for renaming
  • refactoring for redesign
  • etc.

I.e. your example list is really the reason your refactoring, not the subject of the refactoring... the subject of refactoring usually has many overlapping reasons, which is why teams get confused both using and hearing the term... onky in the web world 🤣

Collapse
 
jakub_zalas profile image
Jakub Zalas

I refactor constantly with no mercy as part of my every day work. There’s no need to mention it at all as it’s so common. Just like writing tests. I refactor to make it easier to add a feature, to increase my understanding, to improve readability, etc. Whatever the reason, it’s part of every task I work on. It’s never a separate piece of work.

Having said that, I’m very interested in eventually coming up with a system that Greg Young spoke about in „The art of destroying software”. System so modular that we rewrite its modules instead of refactoring.

Collapse
 
kamlekar profile image
Mr_Green

Yes it makes sense to be precise with the team instead of vague. This gives context to the team and room for quick feedbacks.

Also imo, refactoring must be a team effort not one guys opinions induced on others. For example, renaming of variables to readable names must be a team agreed Dev practices or atleast a quickly consented one. At the end the code must be as if one guy wrote it but not visibly bunch of devs with different opinions/approaches.

Collapse
 
webdevqueen profile image
Andy The Web Dev Queen

The communication is always very important, especially when you deliver the product directly to the client. The client usually wants to know what exactly you did with his money and the benefits of such change. It also increases your value in his eyes when you can talk about reasons with confidence and have data/knowledge you can share to prove them.

Collapse
 
neatshell profile image
Claudio Stella

I would just add, don't refactor if there are not enough tests that prove that everything is working correctly. And if there are not tests write them first. So don't , don't refactor for the sake of it.

Collapse
 
xwero profile image
david duymelinck

I agree with you with the part that refactoring means just pushing code around without a benefit.

The one case you missed, which is a cause that happens most often, is an update of the language/framework/solution. Of course you need to decide the update is worth the work that is needed for the refactoring.

I think refactoring isn't a term that should retire. Only do refactoring that makes things better.

Collapse
 
msedzins profile image
Mirek Sedzinski

Most code refactoring should happen as a side activity, and you don't have to even mention about it (except maybe a comment in PR).

Very basic example: i worked on feature X and at the same time i found a typo in a variable name and fixed it. Or i added one test that i thought was missing.

If you plan to work 1 day on improving a performance of something (your example) then you'd better discuss it in advance, agree and plan.

Collapse
 
nick227 profile image
Nicholas Rios

Depends on your audience. PMs don't know the difference.

Collapse
 
katafrakt profile image
Paweł Świątkowski

They often do.
But even if we assume they don't, it to no one's gain if they start associating refactoring with slacking off.

Collapse
 
m4rcxs profile image
Marcos Silva

It always depends...

Collapse
 
thanhdev profile image
To Thanh

Tbh when I have to report what I did yesterday and I did nothing, I would say I refactored something.

Collapse
 
ss_ss_ea32e46032632ae6332 profile image
ss ss

You are funny. Do not refactor the code. How about do not make bullshit content, if nothing to say

Collapse
 
jkarelins profile image
J Karelins

..., until it works 😅