Um dia na vida de um desenvolvedor Go: código, microsserviços e silêncio em produção

Introdução: Mitos e realidade do programador Go

Na comunidade de TI, existem duas opiniões polares sobre o trabalho de um desenvolvedor Go. Uns dizem que é o paraíso do perfeccionista: tipagem forte, ausência de herança de classes e compilação relâmpago. Outros — que são infinitos if err != nil e a luta com generics (embora já tenham sido adicionados).

Onde está a verdade? Como realmente é o dia de trabalho de um desenvolvedor Go em uma empresa de médio porte que escreve microsserviços de alta carga? Hoje vou abrir a porta para a minha realidade. Sem enrolação — apenas código, ferramentas e casos reais.

Trabalho em uma empresa de produto onde Golang é a linguagem principal do backend. Nossa stack: gRPC, PostgreSQL, Kafka, Kubernetes. Uma história típica para o desenvolvimento moderno em Go. Vamos lá.

08:30 — Manhã: Planejamento e code review

O dia não começa com café, mas sim verificando notificações no GitLab e Slack. Enquanto a mente está fresca, é a melhor hora para revisar Merge Requests dos colegas.

Rotina matinal: O que verifico primeiro?

\n
• Erros no CI/CD — se a build falhou durante a noite, essa é a primeira tarefa.
\n
• Comentários no meu código — em Go, é comum fazer revisões detalhadas.
\n
• Gráficos de monitoramento — a latência não aumentou após o deploy de ontem?
\n

A propósito, sobre code review. Na comunidade Go, existe uma regra não dita: o código deve ser simples. Se você escrever algo complexo e rebuscado, será reprovado na revisão. Exemplo de um comentário típico de um sênior:

// Ruim: abstração excessiva\ntype Processor interface {\n    Process(ctx context.Context, data []byte) ([]byte, error)\n}\n\n// Bom: apenas uma função\nfunc Process(ctx context.Context, data []byte) ([]byte, error) {\n    // lógica\n}\n

Às 09:00 — daily. Não perdemos tempo com longas histórias. Formato: o que fiz ontem, o que farei hoje, há algum impedimento. Nada de "como foi seu jantar".

09:30 — Imersão no código: Escrevendo um microsserviço em Go

Hoje no plano — melhoria no serviço de notificações. É um microsserviço clássico em Go que recebe eventos do Kafka e envia e-mail/push. Tarefa: adicionar suporte a templates.

Primeiro, abro a estrutura do projeto. Em Go, é comum uma árvore de pastas minimalista:

notifier/\n├── cmd/\n│   └── server/\n│       └── main.go\n├── internal/\n│   ├── handler/\n│   ├── service/\n│   └── repository/\n├── pkg/\n│   └── models/\n└── go.mod\n

Começo pelo modelo de dados. Em Go, para trabalhar com banco de dados, costumam usar Go ORM (ex.: GORM) ou consultas SQL puras com sqlx. Prefiro sqlx — menos mágica, mais controle.

type Template struct {\n    ID      int64  `db:"id"`\n    Name    string `db:"name"`\n    Content string `db:"content"`\n    CreatedAt time.Time `db:"created_at"`\n}\n\nfunc (r *Repository) GetTemplateByName(ctx context.Context, name string) (*Template, error) {\n    var t Template\n    err := r.db.GetContext(ctx, &t, "SELECT * FROM templates WHERE name = $1", name)\n    if err != nil {\n        return nil, fmt.Errorf("get template: %w", err)\n    }\n    return &t, nil\n}\n

Observe o tratamento de erros. Em Golang, não existe try-catch. Cada chamada de função é verificada quanto a erros. Isso não é um bug, é uma feature — o código se torna previsível. Em 5 anos de trabalho, nunca peguei um null pointer inesperado em produção.

11:00 — Integração com gRPC

Próxima etapa — adicionar um endpoint gRPC para o painel administrativo. No desenvolvimento moderno em Go, o gRPC se tornou padrão para serviços internos. É mais rápido que REST e gera clientes automaticamente.

Primeiro, descrevo o arquivo proto:

syntax = "proto3";\n\npackage notifier;\n\nservice TemplateService {\n    rpc CreateTemplate (CreateTemplateRequest) returns (TemplateResponse);\