hard or soft code and design? that is the question. and welp, there's a reason we call it "soft" ware
the soft in software means that the code and design must be malleable and durable
- malleable code is easy to change/refactor without having to jump many dependency/build/compilation hurdles
- durable code is easy to change/refactor without breaking other parts of the code
the design ninja masters and even doting design stans like myself talk about "good" solid design, and about supple and strategic design (#ddDesign). design that elicits high UX for other devs i.e. DX (@CarlosRucker); regardless of paradigm i #ooDesign#functionalProgramming, etc
good supple design/code is arrangement of software elements, in a way such that
- the code clearly expresses it's intent and corresponding user scenario in the stakeholders' language
- the code is SOFT, i.e. malleable, changeable, durable
the soft supple design/code we wanna produce is achieved through use of modeling patterns like:
and "beautiful looking code structure, objects/ APIs that are enjoyable to code with come also come out of
- solid, grasp, principles
- gang of four patterns
- kiss, damp, dry, yagni, tda, pola practices
hardness in design and code can manifest as rigidity and or fragility
- fragile code is easy to change/refactor but also easy to break
- rigid code is hard to change/refactor due to constraints with dependencies/build/compilation
being able to name these conditions of hard and software rigidity, fragility, arms you with justifiable motivations for
demanding the time and space needed to produce the code quality you want to; here you know how to concisely describe a situation you want to avoid
appendix: there are more terms that illustrate poor design like immobility, and viscosity
- immobile code, you avoid reusing as it carries too many dependencies or tech baggage
- viscous design is all over the place, without a clear theme or vision, not uniform, hacky
and there is brittleness vs durability which afaik are other qualities that go more into the functional aspect of the system;
but here im more interested in application design/architecture than the runtime aspects
my code used to stink at first. and stink bad. i have produced all manner of rigid, fragile, immobile, viscous, brittle, rotten code in my time.
then i learned about code smells, developed a sense for anti-patterns over time. learned about patterns. and the anti-patterns i was following. and after breaking things, making coding life hard for myself and other devs, now my code is still funky but in the better sense lol 😅
anyways that was another lil ramble for the time being; these are some patterns and principles i practice in my work daily; always a work in progress toward self/craft mastery
ref: the blue book #DDDesign
ref: cvc.uab.es/shared/teach/a…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Domain Driven Design (DDD) made plain broke down to the bone gristle. cus i need that science to level up my code, but miss me with all the stuffy acronyms and jargon. 🧵
domain
- the actual problem
- what we're trying to solve with the code for the user
- the set of problems that the users ask the developers to solve
- the subject matter
domain driven
- problem focused
- to stay focused on the actual problem
For me, when the need for a new language, library, framework, shiny thing, etc pops up - i find that i usually take the same general steps
and the 7-bullet list i jotted down in my notes became this thread:
1. pick a language, any language. or framework, library etc.
no tech is perfect. don't sweat it the choice too much. they all have pros and cons - but do try to pick one that has good community adoption so you can get help when you run into blockers
"Always implement things when you actually need them,
never when you just foresee that you need them." - Ron Jeffries
i feel attacked 🙄
(over-abstraction is one of my guilty pleasures) 😅
like, sometimes i'll take that advice to "code to the interface" to the extreme, just cus i can, and i'll make everything an interface. what you can do with polymorphism and dependency injection is fun ...
but man is it an over-abstraction time suck when trying to just focus on "keeping it simple" KISS minimum viable product. gotta draw the line somewhere and make concrete classes and move forward ...