DEV Community

loading...

Discussion on: 5 habits every developer should adopt!

Collapse
andreidascalu profile image
Andrei Dascalu

Just a note, dry is not about code, it's about knowledge. verraes.net/2014/08/dry-is-about-k... Makes a nice concise example about the difference.

Also DRY is not an absolute principle. It's good, sure but it's nearly impossible to ensure in large projects.
It's a nice ideal but imagine a large team. How would you ensure knowledge about existing representation? Mandatory research before any new feature? We all know no documentation is perfect....

WET can be a nice compromise, where two concurrent independent representations are allowed but never 3 (a third would result in refactoring)

Collapse
tilkinsc profile image
Cody Tilkins • Edited

In terms of abstraction, I will create the all new acronym PAPAGO - pick a paradigm and go. If you plan to write something that has the same lifestyle compared to others, you should probably box that in some guiding interface - pick a paradigm. How should I represent this code?

This way you not only have a structure to build off of, but it greatly reduces the amount of code. Otherwise, every other class is going to have a Load function. Some named differently. Especially if said code doesn't use the Load function in the first place. A nice interface to a class like this would be would be ILoadable and you can separate the loadables from the unloadables.

Having a neat structure means you can easily batch things together and have a fairly nice stack unwrap when something bad happens. I stay away from abstract classes as much as possible in place for interfaces. They bridge the gap of 'Mandatory research before new feature' by having something you can easily walk through not only in code, but again the stack unwrap.

There is a difference between 'oh one of my classes failed to load' and 'oh one of my loadable classes failed to load' that only experience can make you appreciate.