re: Human Readable JavaScript VIEW POST

FULL DISCUSSION
 

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."

 

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.

 

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 🤣😅

 

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
 

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

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?

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

code of conduct - report abuse