23

Don't you hate it when your co-worker does dumb things, but thinks it's the "clean code" way?
The following is a conversation between me and a co-worker, who thinks he's superior to everyone because he thinks he's the only one who read the Clean Code series. Let's call him Bill.

Me: I think the feature we need is quite simple, our application needs to call this third party API, parse the response and pass it to the next step. Why do you need to bury everything under an abstraction of 4 layers?
Bill: bEcAuSe It'S dEcOuPlInG, aNd MaKe ThE cOdE tEsTaBlE
Me: I don't know man, you only need to abstract the third party api client, and then mock it if you want. Some interfaces you define makes no sense at all. For example, this interface only has 1 concrete implementation, and I don't think it will ever have another. Besides, the concrete implementation only gets the input from the upper layer and passes it down the lower layer. Why the extra step? I feel like you're using interface just for the sake of interface.
Bill: PrOgRaMmInG tO iNtErFaCe, NoT cOnCrEtE iPlEmEnTaTiOn!!!
Me: You keep saying those words, I don't think they mean what you think they mean. But they certainly do not mean that every method argument must be an interface
Bill: BuT uNcLe BoB blah blah blah...
Me: *gives up all hope*

Comments
  • 5
    Is that me by any chance ? 😁
    tho I don't use bob as the reason...
  • 10
    I like those principles, and I have a desire to use them

    ... but not if that involves creating more files and brain complecity than it's worth
  • 4
    I'm in the danger zone for this kind of "thinking". Pray for me.
  • 3
    @ihatecomputers
    PrayFactoryInterface pF = new PrayFactory();

    PrayerInterface p = pF->getPrayer();

    p->execute();
  • 2
    @alexbrooklyn haha, stop. Don't give me any ideas.
  • 3
    Is it bad? I often regret not doing it like that early on when things change.
  • 1
    Ahhh..the sweet smell of code addiction.
  • 0
    If you want to have unit tests on each level, yeah do that. Its unwieldy woth new codebases but better in the long run.

    That is if there is a long run for that codebase.
  • 1
    @ihatecomputers don't forget that under p->execute(), an instance of executor interface is created by another factory, which then passes data to the Church API client, which is also an interface of course, so that you can mock the sending of prayers without sending it to a real church. Also, the sending prayer method will need a dependency of God Interface, because you want to mock God in your unit tests too!
  • 0
    @Xamenyap Mocking God, uh-oh 🤔
  • 1
    I once saw a project where every class had an interface. Was an utter mess.
  • 1
    @craig939393 I think not having good abstractions is equally bad, maybe even worse. But overusing abstractions make the code really ambiguous. It takes a lot of effort to understand a single feature in the project I mentioned above. Maybe it's best to find a balance?
  • 0
    @Xamenyap it's good to aim for balance but unfortunately, in most teams, there is someone who wants to apply the last thing that he read about without thinking about consequences and if you try to reason with him he ends up by bringing up a name (like in your case), I hope he is not your team lead.
  • 0
    @irene Correct, they can only tell you when you broke something. So if the application is only gonna sit on a shelf and go away. Who cares?
Add Comment