3 ms·
I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and
by dvh 4y ago
I have reached similar conclusion. DRY projects tend to snowball over the years into mess where every minor change is insanely difficult, breaks everything and code is hard to read, bugs are difficult to solve, diffs are difficult.
WET code (opposite of DRY code, often starts as copy pasted) has more code, more typing, but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 different places which is easy to solve). After many iterations, what started as very similar "classes" is now completely different.
One look at WET class and you know what it does, you change one line and you're done, maybe you need to copy it to 2-3 other files, maybe you don't. In comparison, you'll stare at DRY class for 2 hours and realize you need to refactor absolutely everything, it will break half of the codebase and diffs are insanely complicated.
I've recently wrote 2 similar projects, one wet one dry and wet one is simpler, easier to maintain, and more enjoyable to work on. Dry is root of all evil.
- drKarl 4y agoIf you have the same code copied to several places it makes it much harder to maintain. If there you find a bug in that code block then you have to fix it in several other places, and if you forget some, a bug that you thought you had already fixed might arise again.
- ozim 4y agoHow often do you really write the same piece of business logic code in multiple places? I think discussion is that mostly it really is different code that only superficially looks the same. I don't like pizza example. But I have seen more issues because people were trying to cram code that looks the same in one function than some bug needed to be fixed multiple times because code was duplicated. You also have layers of code and DRY best applies to things like "SaveStuffToDatabase" or framework code. Where a lot of business code can still be better off duplicated because usage will evolve in different ways like: CreateNew vs EditExisting - there is a lot of business cases where when creating new entity you want to set some values that should never be available in Editing - but saving to database should be just saving to database...
- kitkat_new 4y ago> How often do you really write the same piece of business logic code in multiple places? well, depends if you avoid DRY or not. If you apply DRY, zero times.
- ozim 4y agoThink again. Read with understanding. What is really the question that is asked?
- Double_a_92 4y agoUntil you end up with multiple similar pieces of code, that seem to do exactly the same thing except for a few small changes... and you wonder if maybe all the other copies would benefit from those changes too.
- tasuki 4y agoOooh, I spent a lot of time doing this! Good times... then I told the lead about svn:externals and we gradually mitigated some of the pain. To the lead's credit he was humble and open to proposals while I was an asshole about it.
- goatlover 4y agoWhy would you want to maintain basically the same code in multiple places? That sounds more error prone to me. If the DRY code becomes too complicated then refactor it as needed.
- gjulianm 4y ago> but the diffs are simple, bugs are simple (often you simply forgot to copy piece of code into 7 different places which is easy to solve) I am sorry but that sounds like an absolute nightmare. 7 different places means 7 different times that bugs might crop up because you forgot, specially if it isn't documented that you need to copy the code in other places. It also seems a nightmare to maintain documentation about that, as comments might get lost or not updated in all the copy paste. Of course, unit tests are out of the question, are you writing 7 slightly different unit tests and keeping them updated? And I'm supposing it's simple bugs, not pervasive, hard-to-reproduce, indirect bugs that take days just to find the root cause. > In comparison, you'll stare at DRY class for 2 hours and realize you need to refactor absolutely everything, it will break half of the codebase and diffs are insanely complicated. Sounds like a problem of overcomplicated, bad coding and bad documentation. It's not a problem with DRY.
- jugg1es 4y agoI agree with you in principle but your example sounds like a nightmare to me. Aren't you tired of having to make the same change 7 times?