34

😅 What's your thought on introducing abstraction early?

Comments
  • 3
    Don't get me started about DRY vs WET 😅
  • 6
    I normally go full fractal abstraction and then regret it later.
  • 1
    Make it work first; only then start thinking of optimising it.
  • 6
    Nope. Don't abstract, until you actually need it.
    It is much better to plan/design first - and intruduce sane abstractions.

    Some devs (looking at you, Java) - abstract just because. Don't. If you have only one concrete Class - no need for that crap.
  • 2
    @magicMirror Exactly! When I told this to my interviewers, they asked how you are so sure that no implementation will come in the future. I answered that then I will introduce an interface for that. They asked why not now then. Then, I went silent. 😵
  • 1
    Abstract everything, specially in C++ with Multiple Inheritance. It's job security, guaranteed.
  • 0
    @kamen who said something about optimizing? 😄
  • 0
    @Lensflare I meant the implementation.
  • 0
    I ask: "this thing you wanna abstract: is it a standard well known concept? how many props does the abstraction save us from typing on average?"

    It's silly to abstract stuff like fetch requests or an IMG tags since those are so well known devs can handle them in their sleep

    UNLESS most of you often use these in ways which require vast amounts of properties like IMG srcSet or tons of fetch headers

    Second question is to try it out on 2 fellow devs and see if they intuitively get the abstraction and can start using it in an example without forgetting how it works
  • 1
    There's a very simple rule: If you can formulate in a sentence with present tense and no expression of possibilty why you need abstraction, go for it.

    It could... Nope.

    In the future... Nope.

    We might... Nooooope.

    If we add this now ... Still no no.

    To support the multiple types of commands we have via polymorphism. ... Now that sounds good.

    To make it work... No - go fuck yourself ;) :-)
  • 2
    @cypher-clown
    Continue with:
    Easier to implement now.
    The KISS principle.
    Simpler to QA.
    And most important: Deliver on time.

    Coding using the "We Might Need It In The Future" idea, is wasteful, and costs money and time.
  • 1
    It’s not that hard to abstract something later as long as you recognize when you need it. It’s harder when you’re building on top of things that should have been abstracted.
  • 0
    Some good points here about avoiding "need it in the future".

    One situation which is tricky though is if you've got a lot of time now - but have an upcoming stressful period, so you figure you could lay some groundwork now. Ideally you can wait and refractor on the fly as needed but sometimes schedules make you feel like trying to anticipate upcoming needs.
  • 0
    I always regret it
Add Comment