Go Anti-Patterns & Code Smells on Atharva Pandey

Lesson 10: Over-Engineering CRUD — Not every API needs a hexagonal architecture

Wed, 02 Jul 2025 00:00:00 +0000

There is a category of service that I have built many times and will build many more times: an API that creates, reads, updates, and deletes records in a relational database, with some validation and authentication. There is nothing glamorous about it, and there is nothing architecturally complex about it either. The correct implementation is straightforward, fast to build, easy to test, and easy to read. The over-engineered implementation has event sourcing, CQRS, a message bus, six layers of abstraction, and takes three months to build something that the straightforward implementation would have shipped in two weeks.

Lesson 9: Fake Clean Architecture — Layers without purpose are just folders

Tue, 20 May 2025 00:00:00 +0000

I cloned a Go repository that was described to me as a “clean architecture” implementation. It had six layers: handler, usecase, service, repository, model, and dto. Every user-related operation required touching at least four files across four packages. When I added a new field to the user profile, I updated the database schema, the model.User, the dto.UserDTO, the repository.UserRepository, the service.UserService, the usecase.UserUseCase, and the handler.UserHandler. Eight files for one field. The indirection was total, the business logic was nowhere — it was scattered across the layers in thin delegating functions that called the layer below and returned the result.

Lesson 8: Premature Abstraction — Wrong abstraction costs more than duplication

Wed, 02 Apr 2025 00:00:00 +0000

There is a principle in software development — “Don’t Repeat Yourself” — that is so widely known it gets abbreviated to DRY and invoked to justify almost any abstraction. The problem is that DRY is a principle about knowledge, not syntax. Two pieces of code that look the same but represent different concepts should stay separate. Two pieces of code that represent the same concept should indeed be unified. Most premature abstractions happen when developers see syntactic similarity and immediately reach for abstraction, before they understand whether the similarity is incidental or fundamental.

Lesson 7: Panic as Error Handling — Panic is for bugs, not business logic

Tue, 18 Feb 2025 00:00:00 +0000

I have reviewed Go code from developers who learned other languages where exceptions are the primary error handling mechanism. In Ruby, Python, or Java, you throw an exception and it propagates up the stack until something catches it. In Go, the analogous mechanism — panic — has a very different contract. A panic that is not recovered crashes the entire process. In a web server, that means every in-flight request dies. In a worker process, that means all queued work is dropped.

Lesson 6: Swallowing Errors — The silent failure that cost us 3 hours

Sun, 12 Jan 2025 00:00:00 +0000

We had a deployment where user preferences stopped being saved. New preferences were accepted by the API — the endpoint returned 200 — but nothing was written to the database. After three hours of debugging we found it: a defer rows.Close() inside a transaction helper that was discarding the error from tx.Commit(). The commit was failing silently, the defer returned without error, and the handler sent a success response. The only indication anything was wrong was a metrics counter nobody had set up an alert for.

Lesson 5: Ignoring Context — The cancellation nobody checked

Fri, 22 Nov 2024 00:00:00 +0000

I spent a Tuesday afternoon tracking down why our service continued doing expensive database work after clients had long since disconnected. An HTTP client with a 3-second timeout would cancel the request, but our handler would still run three downstream database queries that together took 8 seconds. The handler was checking for errors but never checking the context. By the time it finished, the client had retried twice, and we were now running three copies of the same 8-second work simultaneously.

Lesson 4: Channel Misuse — You used a channel where a mutex would do

Tue, 15 Oct 2024 00:00:00 +0000

Go’s channels are genuinely great. They make certain concurrent programming patterns — pipelines, fan-out, fan-in, worker pools — natural and readable. Because they are idiomatic and distinctly Go-like, there is a tendency among Go developers to reach for them first whenever concurrency is involved. The result is code that uses channels to protect shared state, which is what mutexes are for, or code that passes one value through a channel with ceremony that could be replaced by a function call.

Lesson 3: Global Mutable State — The variable that breaks every test

Thu, 05 Sep 2024 00:00:00 +0000

There was a test suite I worked on where tests passed individually but failed when run together. The failure pattern was non-deterministic — sometimes test A broke test B, sometimes test C broke test A, and it changed with the -count flag. After two hours of bisecting, we found it: a package-level var config Config that every test modified by calling loadConfig("testdata/some-fixture.json"). The tests were sharing state without knowing it, and the one that ran last set the config for all the others.

Lesson 2: Giant God Structs — If your struct has 30 fields, it has 30 problems

Thu, 25 Jul 2024 00:00:00 +0000

I inherited a Go service where the primary domain object was a struct with 47 fields. Some were database columns, some were computed from other fields, some were HTTP response projections, some were used only during a specific workflow stage, and a handful were there because someone once needed a flag and adding a field to the God struct was the path of least resistance. The struct was everywhere — passed between functions, serialized to JSON, written to the database, and used as a GraphQL response type. Every change to it rippled through the entire codebase.

Lesson 1: Interface Everywhere Syndrome — Not every dependency needs an interface

Tue, 18 Jun 2024 00:00:00 +0000

When I came to Go from a Java background, I brought some habits with me that made my code worse, not better. The most persistent one was defining an interface for every dependency, regardless of whether there was any realistic chance of substituting an alternative implementation. I wrote UserRepositoryInterface, EmailSenderInterface, LoggerInterface — an entire shadow type system that mirrored every concrete type in the codebase. Every file had a corresponding interface file. The codebase was twice as large as it needed to be and no easier to test.