Pretty easy to give generic advice without examples.
“Write more tests, but not too many”
“Use good abstractions where appropriate?”
“The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?”
It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone.
Of course people want to use good abstractions.
That’s not the problem.
The problem is being able to tell the difference between generic arbitrary advice (like this post) and how your specific code base needs to use abstractions.
…and bluntly, the only way to know, is to either a) get experience in the code base or b) read the code that others have left there before you.
If it’s a new project, and you’re not familiar with the domain you’ll do it wrong.
Every. Single. Time.
So, picking “good” abstractions is a fools game.
You’ll pick the wrong ones. You’ll have to refactor.
That’s the skill; the advice to take away; how to peel back the wrong abstraction and replace it with your next best guess at a good one. How to read what’s there and understand what the smart folk before did and why.
…so, I find this kind of article sort of arrogant.
Oh, you want to be a great programmer?
Just program good code.
Use good abstractions. Don’t leave any technical debt. Job done!
…a few concrete examples would go a long way here…
“Write more tests, but not too many”
“Use good abstractions where appropriate?”
“The next time you reach for an abstraction, ask yourself: Is this truly simplifying the system? Or is it just another layer of indirection?”
It’s easy to create a strawman here (the FactoryAdaptorMapper or whatever) but in reality this kind of generic advice doesn’t help anyone.
Of course people want to use good abstractions.
That’s not the problem.
The problem is being able to tell the difference between generic arbitrary advice (like this post) and how your specific code base needs to use abstractions.
…and bluntly, the only way to know, is to either a) get experience in the code base or b) read the code that others have left there before you.
If it’s a new project, and you’re not familiar with the domain you’ll do it wrong.
Every. Single. Time.
So, picking “good” abstractions is a fools game.
You’ll pick the wrong ones. You’ll have to refactor.
That’s the skill; the advice to take away; how to peel back the wrong abstraction and replace it with your next best guess at a good one. How to read what’s there and understand what the smart folk before did and why.
…so, I find this kind of article sort of arrogant.
Oh, you want to be a great programmer?
Just program good code. Use good abstractions. Don’t leave any technical debt. Job done!
…a few concrete examples would go a long way here…