DEV Community

Discussion on: Human Readable JavaScript

Collapse
 
jacobmgevans profile image
Jacob Evans

Love the point free (tacit programming) put in there. I am getting more into functional programming but have to consider my peers and juniors coming in when writing my code... Usually, I ask myself "could I have understood or figured this out when I first finished my coding Bootcamp...? If no I refactor."

Collapse
 
laurieontech profile image
Laurie

What a great barometer!

Do you think you're losing sight of that level at all? That's always my fear. That I overestimate my past self.

Collapse
 
jacobmgevans profile image
Jacob Evans

Sometimes I do. I generally will have mentees or people I know learning code take look. If they have trouble understanding it ill have them describe why to be sure it's not just a knowledge issue but an over-complicated issue. 😆 So far it seems somewhat successful. I still write my own esoteric code on personal stuff lmao 🤣😅

Collapse
 
_ezell_ profile image
Ezell Frazier

That's a really good principle to work by.

Refactor only if:

  • It has bugs
  • A junior dev would be stressed out trying to read it
Collapse
 
pedro00dk profile image
Pedro Henrique • Edited

I think you should fix it, not refactor if it has bugs.
By definition, refactoring does not change behavior.

Thread Thread
 
_ezell_ profile image
Ezell Frazier

True, but when we encounter bugs, don't we ask what caused the bug? Too many moving parts? Unclear data-flow? In the postmortem of a bug-fix, the topic of refactoring doesn't come up?

Thread Thread
 
jacobmgevans profile image
Jacob Evans

Well said Ezell, I agree that refactoring during a bugfix rewrite is a good idea for sure!