Premature Refactoring

Premature Refactoring

Snippets from https://medium.freecodecamp.org/refactoring-oops-ive-been-doing-it-backwards-55eed503ccd0

Purpose > Principles

"The problem occurs when my code focuses on being SOLID, or pure, rather than on accomplishing what it was born to do. The problem occurs when I put principles over purpose."

First, Make it Work

"mantra, “Make it work, make it right, make it fast.” I’ve realized I’ve been going out of order. I’ve been making it right, making it fast, then making it work!"

"At first don’t worry too much about naming, single responsibility, or being extensible — you’ll address that once your function is working. To be clear, you won’t be writing your whole application like this, just one small piece.

"Once you’ve got the output you are looking for (you’ve got unit tests to prove that the code is correct, right?) begin refactoring, but don’t go too far too fast! For now, stick with refactoring strategies that are in the category of proper naming, functions doing only one thing, and the avoidance of mutation; don’t immediately start making extensible or reusable classes and factories until you have identified a repeating pattern."

Having SOLID code is not a reason

"Having SOLID code is not a reason. Having functional or pure code is not a reason." 

"For example, refactoring the name of a variable to become more accurate will always make sense. Its merit is inherent. Refactoring a function to be pure usually makes sense because side-effects can cause unforeseen issues. Those are reasons."

Dependency inversion is not a reason

"“It’s best practice to use dependency inversion” is not a reason. “Good code is extensible” is not a reason. What if I only have a couple of never-changing dependencies? Do I still need dependency inversion? Not yet. What if nothing needs to extend my code and I have no plans for anything to do so? Should my code increase its complexity just to check off this box? No!"

Stick with the simplest possible pattern (KISS)

"My advice is to stick with the simplest possible pattern."

Vigilant Balance

"As programmers we have to balance code quality, performance, maintainability, with the good old-fashioned need to get things done."

"We have to be vigilant and make sure both needs stay in their correct place. Our code can’t be maintainable if it doesn’t work correctly. On the other hand, it’s hard to make bad code work correctly."