In this blog post, we will explore how to detect and prevent these anti-patterns using pair programming, code reviews, and observability.
This article fails to explore any of that. It very loosely describes some anti-patterns in code (Spaghetti Code, Golden Hammer, Boat Anchor, God Object, Premature Optimization) then attempts to list 4 ways to combat them. But that is it, it just list and describes them without really talking about the how.
The 4 methods are just:
Pair Programming and Code Review - which are basically two flavours of the same thing, getting someone else you look at your code to spot issues. It fails to even mention that at all and just says:
This technique can help in detecting anti-patterns early and prevent their introduction into the codebase.
But the only real way these help at all is if the other person actually knows how to spot and fix the anti-patterns at hand. Which is useless information, it never says why it does that at all nor how you can improve to get better at spotting these issues.
Then takes about Observability and Tracing which I don't see how it is relevant to spotting these or any anti-patterns at all. And nor does the article it basically just says
We can use this information to measure performance before optimizing or to find unused code.
Yeah, no shit. You can use information to inform you about things... Not exactly actionable information there.
Which leads to the crux of the article for Continuous Feedback:
You can start using Digma today without any additional dependencies or configuration. Check out how.
So, an ad. But maybe at least we can see how this tool can mitigate the issues raised at the start?
How I used Continuous Feedback to detect and prevent the premature optimization anti-pattern
Ah, that sounds like it will at least address one of the issues raised at the start. Which is basically:
The first one is to measure performance before attempting to optimize something.
and
The second is when we have a performance problem. The challenge is often to find the bottlenecks, not to fix the performance problem itself.
Which, yeah that is reasonable advice I suppose. But it lacks any interesting details on how it actually helps beyond it collects information and shows some pretty pictures.
It never gets around to talk about the other anti-patterns again. What about them? Does this tool actually help with them at all? Why were they mentioned at all if you just want to talk about how this tool can find performance problems and help fix them? And how does that have anything to do with premature-optimisation?
This would have been better if it just focused how it identifies bottlenecks and finds performance regressions and if went into any details about that. As it stands there is no useful information in the ~~ad~~ article.