Every time I joined a new project, I made it a point to take responsibility for fixing bugs. Why? Because fixing bugs is the best way to understand the architecture and get familiar with the codebase. Often, there’s little to no documentation, and all the knowledge is locked inside the developers’ heads. By fixing bugs (and writing tests as I went), I created my own map to navigate the codebase, uncover its quirks, and ensure I wasn’t lost. ...
Years ago, before JavaScript made its way to the server side (yes, that’s an important digression, believe it or not), One of my colleagues once shared an intriguing observation with me: backend programmers, whether they come from a C# or Java background, often resemble drivers switching to bicycles when they start programming in JavaScript. It’s as if they forget all the rules. And here’s the thing: I think this observation holds true. Back then, JavaScript wasn’t respected. It was dismissed as a “dumb language.” A toy for web designers to sprinkle some interactivity onto their pages. Fast forward 15 years, and while JavaScript has become a powerhouse, I still see controversial code written by experienced programmers from so-called “real” languages. It’s the kind of code that makes you wonder if they left their instincts and good practices behind when they crossed over. ...
I was looking for distilled information about clean architecture in the context of GO. In the meantime, my colleague found (in my opinion) the best article that describes this topic in great depth: https://pkritiotis.io/clean-architecture-in-golang/ In general I like most of it. However, what I don’t like is that every handler’s builder returns an interface instead of a concrete struct, and the domain defines the repository interface. Here’s why returning the concrete structure might be a better choice in many cases: ...