This post was first published on CoderHood as Choosing The Proper Level of Abstraction. CoderHood is a blog dedicated to the human dimension of sof...
For further actions, you may consider blocking this person and/or reporting abuse
Interesting. I'd add the notion of pain in the ass. Whenever I code something, I basically do the following:
(the more experienced you get the more you can do parts 1 to 4 in your head)
Then obviously, when some new feature comes in:
The main idea here: factorize/automate when it hurts.
I use TDD as a thinking tool in my development workflow. By doing this I can often avoid big up front design while driving towards the correct balance of abstraction. I always start by making it work, just puke the code in my brain on the screen, then make it pretty (reflect upon and refactor) my code to include any learning I may have discovered. I continue this process while pushing back against a tension of poor design / under abstraction until I can see concepts emerging.
I then collect these into methods and classes as I think about SOLID and Single Level of Abstraction during my reflect/refactor step of the TDD cycle.
This allows me to solve the problem at the micro-scale, thus rooting out the many assumptions I have when only solving in my mind or all at once. Our minds are horribly irrational and prone to biases, thus trying to problem solve at the macro-scale is an exercise in frustration and bugs.
By using TDD to slice the problem up, I am able to build context and grip the problem properly before I worry about the elegance of my solution.
Experience is a big factor in slicing the problem and applying TDD to guide my thinking. I like to remind myself TDD is any developer written test. Be it unit, integration, BDD, learning, etc. They all help guide and document my understanding of the problem at the various levels of complexity in the given domain.
I never managed to do TDD. Even though I tried, it's just too hard for me.
I'm fine with testing but if you write your tests afterwards.
What I do however is, whenever I write an API (not a REST one), I start by writing on a paper how I want to use it. And then I figure out the internals.
Excellent article as always. Totally resonates with my experiences and well explained.
Truly wonderful read.
Thank you, Ben!!
For some reason, writing this post was like giving birth to a child (speaking as someone who never gave birth to a child). It took way too many hours. Maybe because of all the photoshopping of the images, or maybe is because it was hard to be happy with the definitions...
But the final result is excellent. Great article.
Thank you, Rafal!!
This is brilliant - and did make me chuckle as some of it is a little too familiar from some past projects!
Somebody built a super-computer when they were asked to build a pocket-calculator? :-) I know, it is a pretty familiar sight, isn't it?
Thank you for reading!!
Fantastic reading.
And you made a right level of abstraction describing the problem as black ink splatter :)
Awesome! I was hoping someone would notice the meta-aspect of the analogy 😊