I find this discussion on javascript, principles and architecture interesting as the area is an evolving field, and people find ways of apply well-established concepts in new ways.
Regarding reason to refactor:
In my experience, the most common and valid reason to refactor is a change in requirements. Your old code now solves the wrong problem.
Working on enterprise systems bigger refactoring jobs takes time and for outside stakeholders this can seem to give them zero business value, thus they will fight it.
Regarding principles I primarily stick with KISS, DRY and YAGNI rather than SOLID.
Take YAGNI - You Ain't Gonna Need It. Related to KISS.
For me, it means more than removing unused code. It also applies to how you write code: don't write code more generic or complex than is needed. This might be controversial because we tend to plan ahead, preparing for the next sprints by writing generic code. It follows from another principle, DRY (Don't Repeat Yourself).
Requirements do change however, so you might get a larger restructuring work later from over-engineering the first solution. Change is what agile is all about.
Generic code can have a price in readability, so that needs to be traded off against the value it provides.
DRY and YAGNI might feel contradictory, with one excluding the other. This is not the way I see it, and they can both be applied to varying degrees.
One problem might varrant a solution that applies them 60-40 or 20-80. It comes from experience and gives the best of two worlds.
Balance is the word you mentioned and I tend to agree on it.
Not all principles apply equally well, and not all problems require a hammer to be fixed :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for nice reading!
I find this discussion on javascript, principles and architecture interesting as the area is an evolving field, and people find ways of apply well-established concepts in new ways.
Regarding reason to refactor:
In my experience, the most common and valid reason to refactor is a change in requirements. Your old code now solves the wrong problem.
Working on enterprise systems bigger refactoring jobs takes time and for outside stakeholders this can seem to give them zero business value, thus they will fight it.
Regarding principles I primarily stick with KISS, DRY and YAGNI rather than SOLID.
Take YAGNI - You Ain't Gonna Need It. Related to KISS.
For me, it means more than removing unused code. It also applies to how you write code: don't write code more generic or complex than is needed. This might be controversial because we tend to plan ahead, preparing for the next sprints by writing generic code. It follows from another principle, DRY (Don't Repeat Yourself).
Requirements do change however, so you might get a larger restructuring work later from over-engineering the first solution. Change is what agile is all about.
Generic code can have a price in readability, so that needs to be traded off against the value it provides.
DRY and YAGNI might feel contradictory, with one excluding the other. This is not the way I see it, and they can both be applied to varying degrees.
One problem might varrant a solution that applies them 60-40 or 20-80. It comes from experience and gives the best of two worlds.
Balance is the word you mentioned and I tend to agree on it.
Not all principles apply equally well, and not all problems require a hammer to be fixed :)