go-patterns

Use functional options: define `type Option func(*Server)` with `With*` builder functions, and a `NewServer(addr string, opts ...Option)` constructor that applies defaults first. Return an error from options only when validation can fail, and reserve the builder pattern for complex multi-step validation.

Walk the anti-pattern checklist against the changed code, checking each category: abstraction, coupling, error handling, concurrency, testing, and security. Score each finding by severity, note the file and line, and record the idiomatic replacement pattern for each issue.

Use clean architecture for medium-to-large services needing strong separation between business logic and infrastructure via use cases and the dependency rule. Choose hexagonal architecture when the same domain logic must serve multiple entry points like HTTP, gRPC, and message consumers through ports and adapters.

No. `init()` runs implicitly, cannot return errors, and makes tests unpredictable since it executes before main and test functions. Use an explicit constructor like `New(dsn) (*Repo, error)` that returns errors and accepts injected dependencies.

math/rand is a deterministic pseudo-random generator, so tokens and keys derived from it are predictable to attackers. Use crypto/rand instead: read bytes with crypto/rand.Read into a byte slice and encode with hex or base64.

Use signal.NotifyContext with SIGINT and SIGTERM, start the server in a goroutine, then block on context cancellation. Call srv.Shutdown with a timeout context to drain in-flight requests, then close remaining resources like database connections in order.