3 ms·

DDD, Microservices, Clean, Hex, Onion, TDD, XP, EDA..... All of those follow the basic SOLID principals. The problem is the cargo culting and blog posts vs ac

DDD, Microservices, Clean, Hex, Onion, TDD, XP, EDA..... All of those follow the basic SOLID principals. The problem is the cargo culting and blog posts vs actually reading what the stuff means. S or the Single responsibility principal as an example is always explained poorly by the same people who complain about it. SRP means that "A module should be responsible to one, and only one, actor." An 'actor' being a group that requires a change in the module. making sure you decouple persistence code from domain code is an example. Almost universally the people who complain about SOLID thinks it means that you have to have trivial functions with lots of sprawl. Really it is about allowing you to make changes without stepping on another's toes or trying to coordinate with them.

t8sr 3y ago
Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better. Great! But then those rules got transposed into other situations, possibly by somebody else and things went downhill. Also see "Agile". Our industry, because of its huge growth, is filled with inexperienced people who learned from inexperienced people. We all know software is kind of trash, and we're coming up with ways to improve it, but the fact of the matter is we don't know what works. We know some things that don't work, and many of those were previously on a list of things that might work and had catchy acronyms of their own. A few people have enough experience to give good advice, but what they have to sell isn't a magical silver bullet with a neat acronym, and they don't use twitter, so nobody listens to them. The only thing I personally believe makes you write better code is long and varied experience with different domains, fueled by a desire to always be learning. Throw away mantras when they're no longer useful. Work like this for 10-20 years, and you'll start writing sort of OK code. Everything else ends badly.

t8sr 3y ago

Mantras like these are always a response to something. Someone in charge of technical culture at $PLACE diagnosed specific anti-patterns in their Java code, came up with a set of rules for the noobs and a catchy acronym. Things got better. Great! But then those rules got transposed into other situations, possibly by somebody else and things went downhill. Also see "Agile". Our industry, because of its huge growth, is filled with inexperienced people who learned from inexperienced people. We all know software is kind of trash, and we're coming up with ways to improve it, but the fact of the matter is we don't know what works. We know some things that don't work, and many of those were previously on a list of things that might work and had catchy acronyms of their own. A few people have enough experience to give good advice, but what they have to sell isn't a magical silver bullet with a neat acronym, and they don't use twitter, so nobody listens to them. The only thing I personally believe makes you write better code is long and varied experience with different domains, fueled by a desire to always be learning. Throw away mantras when they're no longer useful. Work like this for 10-20 years, and you'll start writing sort of OK code. Everything else ends badly.