Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
Yah, that makes sense. I think an intuition of the importance of being DRY in any given scenario is valuable.
I'm definitely not promoting laziness or apathy or saying that being DRY is dumb or religiously excessive.
Instead I'm saying that DRY is probably less important than SOLID and less important than the principles of DDD.
I've seen, on many occasions, code that has been preemptively consolidated because at the time of consolidation the multiple pieces looked to be the same.
What was realized later was the code did not have the same meaning or purpose and the different pieces of code would have evolved naturally at different speeds and for different business requirements over time.
What resulted was code that had to suit too many use cases or be re-separated.
The original principles of DRY were meant to encourage developers not to write the same pieces of code multiple times - but this would have been code that was for the same purpose, not just code that looks similar or the same at a given point in the projects history.
Preemptive DRYing reminds me of building a micro-services architecture before understanding the seams in the service boundaries.
Martin Fowler encourages, for many teams, building a monolith first (with SOLID principles) and then separating off pieces once the use-case patterns have been identified.
Let your code grow naturally.
Identify not just what some code does but also why it does it.
Know that many things can be done prematurely (optimization, architecture, DRYing).
Decide if something should be a cross-cutting concern applied through AOP if it feels it should be DRY'd up.
Thanks for the thoughts!
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.
Yah, that makes sense. I think an intuition of the importance of being DRY in any given scenario is valuable.
I'm definitely not promoting laziness or apathy or saying that being DRY is dumb or religiously excessive.
Instead I'm saying that DRY is probably less important than SOLID and less important than the principles of DDD.
I've seen, on many occasions, code that has been preemptively consolidated because at the time of consolidation the multiple pieces looked to be the same.
What was realized later was the code did not have the same meaning or purpose and the different pieces of code would have evolved naturally at different speeds and for different business requirements over time.
What resulted was code that had to suit too many use cases or be re-separated.
The original principles of DRY were meant to encourage developers not to write the same pieces of code multiple times - but this would have been code that was for the same purpose, not just code that looks similar or the same at a given point in the projects history.
Preemptive DRYing reminds me of building a micro-services architecture before understanding the seams in the service boundaries.
Martin Fowler encourages, for many teams, building a monolith first (with SOLID principles) and then separating off pieces once the use-case patterns have been identified.
Thanks for the thoughts!