
Beck Design Rules (2015) - fagnerbrack
https://martinfowler.com/bliki/BeckDesignRules.html
======
Nursie
>Such things as adding duplication to increase clarity is often papering over
a problem, when it would be better to solve it.

So much this, lately. I've found myself unsatisfied with the convoluted code
needed to share some functionality across two similar but distinct areas, and
trying to figure out if the repetition or the convolution is easier to
understand for the reader, and what it means for maintainability.

But really what's tickling me is that there is a better solution waiting in
there somewhere.

~~~
YZF
Compare that with Go's "A little copying is better than a little dependency".

The problem with religious DRY is that the shared bits may eventually evolve
into something that does everything for everyone, used everywhere, and becomes
unmaintainable and buggy. You can't touch it without breaking something. The
notion that tests will guarantee its correctness doesn't tend to work either
since there's no way to cover all of a product's functionality via tests.

I think it's important to look at XP in context, see what issues it tried to
address and how it tried to address them, and try to be pragmatic. There's
certainly local situations where DRY is a good principle but generally you
should strive to break your software down into independently maintainable
pieces with well defined/small-ish interfaces, trying to stretch DRY across
those boundaries would create problems (i.e. the dependency mentioned in that
Go proverb).

