Are You Refactoring Code For The Right Reasons?

It's tempting to jump into refactoring code that's hard for you to understand.

But before you take that leap, you should probably consider that there can be some dangers.

Whether you're coding in Java, Javascript, C#, Python, or any other language - there are non-technical implications of code refactoring that you should be aware of.

In this video, I share 6 considerations to take into account that will help you avoid getting into a stressful situation when you choose to refactor code.

Related Videos:

"Are You A Perfectionist Programmer?"

"Software Developer vs Consultant - What's Better For YOU?"

"An Agile Budget Keeps You From Being A Code Monkey"

"Technology Addiction: Materialism in Software Development"

"Democratic Software Architecture: Sharing Technology Decisions"

#programming #refactoring #code

[MajeureX]

There's no harm in refactoring code if you helps you understand it. For me I find this more effective than reading the code with touching it. Nothing says you have to commit or push the code to the master branch. Some call this 'scratch refactoring'.

[CharlesBallowe]

Just tripped over this older video, but it's something relevant constantly. One thing might be "do I need to understand the code" - rewriting it can help me check that my understanding is correct. Another is how much churn does the code have - if it's being constantly touched, i'd ask if those changes are particularly hard and if restructuring the code would make that easier. If it's not being touched, I'd ask if anybody understands it and if they're avoiding touching it in ways that create more work.

Sometimes it's ok to have a box of black magic in the corner that does what it's supposed to do and nobody has to change it.

[ShotgunAFlyboy]

Sometimes the code *is* just wrong though. Like, I've had to rewrite code occasionally written by people that did not really understand the language they were assigned to work in (and had no interest in learning). This is on a product I'm the final butt on the line for though. My goal is never to make it so I can understand it, it's to make it so my juniors can understand it. Gotta make sure the code is well tested beforehand though, so you don't miss those edges.

[pavelperina]

Without watching more than one minute:
* If code works and seems maintainable, don't touch it
* If code somewhat works and seems hard to maintain, it may have some many dependencies across the project that you can't refactor it and you are doomed to stick with it
* If person who wrote this code is still in the company, try to understand his motivation for writing it "wrong" and try to explain your points how to write it "better" and educate him, maybe the biggest piece of code he wrote was his diploma thesis with 2000 lines and he will respect you.
* it's much more important to have clear and easy to understand interfaces than clean code. If this is messed up, it's failure or lack of experience of the whole team

[HealthyDev]

Have you had to decide whether to refactor code you don't understand? How did you deal with it?

Skip to points:

02:12 How Valuable Is The Change?
03:19 How Much Time Is Needed To Refactor?
05:29 Will Refactoring Handle The Hardest Case?
08:30 Are You Willing To Get Permission?
10:42 Are You Willing To Teach Everybody?
11:59 Are You Willing To Work Overtime?

[ianedmonds]

I got handed an access database which had no constraints or keys and a bunch of remote tables in an SQL database that also had no restraints or keys.
I'd been a .net and SQL programmer for ten years.
It had been made by some nut job outside of IT and when he left it was passed to IT to support.
It was responsible for bidding for work based on part cost plus a multiplier. Really shonky stuff that was flawed in every way.
I looked at the access database and it was truly horrible. The amount of duplicate records was crazy and the disconnect between tables was off the scale.

There were orphaned records everywhere and even the records that were connected via crappy natural keys were suspect.
Loads of duplicates and no sense of normalisation.
Some of the queries were so badly written they were counting some of the costs multiple times.
I have no idea how we stayed afloat with such a dysfunctional tender system for so many years.
I told my boss it was a dead duck and that we should not maintain it.
She insisted we need to fix but asked me to do a report on how broken it was.
I did the report with a scenario where we over bid at 4 pieces for every one in the spec. It could have gone to more if more tables were involved. The database was a complete shitshow.
They retired the app shortly after.
Absolute nightmare of a project.
Luv and Peace.

[SlimAgnus]

In 02:12 you ask how valuable the change is, if it's in a piece of code that doesn't have much impact.

If the code is too complex or too messy for you to understand what it does, without refactoring it, how will you determine if it's worth refactoring?

[henka]

in a C codebase i once saw this:
int* ptr;
ptr = malloc(sizeof(int));
*ptr = 5;
some_func(*ptr);
free(ptr);

i think he got paid by number of code lines.

[pavloburyanov]

Sometimes its impossible to go further without refactoring.

[jtmuzix]

Hello good sir. Are you familar with C++ and if so, how comfortable are you with utilizing the languages pros such as inheritence, encapsulation, and polymorphism?

[xTwisteDx]

Oh I’ve 100% come upon code that was unreadable, and determined it was hot garbage, and refactored it. Absolutely they had done it wrong xD

[watamatafoyu]

Wow, 6 years ago, I've gone down the suggestion hole.

[kdietz]

Oh this sounds like a super fun game. Let's play "would you refactor this code?"

[TomasHayes]

To refactor code you have to understand it first anyway 😅

[JohnMelaries]

If you don't understand the code, read it first and play around with it to understand it.

[JM-jcew]

Great Video Jayme,

Good to have you back, was worried, you were releasing videos less often.

I got in trouble in the past when refactoring, if I do not think the same way, as the programmer who did it.

I got issues with female programmers ha ha ha!

Before refactoring codes, I hit the "blame/show annotation" feature, and if the committer is a female then "Abandon ship!! I repeat, Fall back! fall back! retreat! retreat!".
(Believe me, I've seen twisted things out there, this will save you, a lot of time and trouble, specially on a legacy codebase with poor implementation of encapsulation/basic OOP concepts).