Un día en la vida de un desarrollador Go: código, microservicios y silencio en producción

Introducción: Mitos y realidad del programador Go

En la comunidad TI existen dos opiniones polares sobre el trabajo de un desarrollador Go. Unos dicen que es el paraíso del perfeccionista: tipado estricto, ausencia de herencia de clases y compilación ultrarrápida. Otros, que son interminables if err != nil y la lucha con los genéricos (aunque ya los agregaron).

¿Dónde está la verdad? ¿Cómo transcurre realmente el día laboral de un desarrollador Go en una empresa mediana que escribe microservicios de alta carga? Hoy abriré la puerta a mi realidad. Sin rodeos: solo código, herramientas y casos reales.

Trabajo en una empresa de producto donde Golang es el lenguaje principal del backend. Nuestro stack: gRPC, PostgreSQL, Kafka, Kubernetes. Una historia típica para el desarrollo moderno en Go. Allá vamos.

08:30 — Mañana: Plan y revisión de código

El día no comienza con café, sino revisando notificaciones en GitLab y Slack. Mientras la mente está fresca, es el mejor momento para revisar las Merge Requests de los colegas.

Rutina matutina: ¿Qué reviso primero?

\n
• Errores en CI/CD — si la compilación falló durante la noche, esa es la primera tarea.
\n
• Comentarios a mi código — en Go se acostumbra hacer revisiones detalladas.
\n
• Gráficos de monitoreo — ¿ha disminuido la latencia después del despliegue de ayer?
\n

Por cierto, sobre la revisión de código. En la comunidad Go hay una regla no escrita: el código debe ser simple. Si escribes una solución compleja y rebuscada, te la devolverán en la revisión. Ejemplo de un comentario típico de un senior:

// Mal: abstracción excesiva\ntype Processor interface {\n    Process(ctx context.Context, data []byte) ([]byte, error)\n}\n\n// Bien: simplemente una función\nfunc Process(ctx context.Context, data []byte) ([]byte, error) {\n    // lógica\n}\n

A las 09:00 — reunión diaria (standup). No perdemos tiempo con historias largas. Formato: qué hice ayer, qué haré hoy, si hay bloqueos. Nada de «cómo estuvo tu tarde».

09:30 — Inmersión en el código: Escribimos un microservicio en Go

Hoy en el plan: mejorar el servicio de notificaciones. Es un microservicio clásico en Go que recibe eventos de Kafka y envía correos electrónicos/push. Tarea: agregar soporte para plantillas.

Primero, abro la estructura del proyecto. En Go se acostumbra un árbol de carpetas 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

Empiezo con el modelo de datos. En Go, para trabajar con bases de datos se suele usar Go ORM (por ejemplo, GORM) o consultas SQL puras con sqlx. Yo prefiero sqlx — menos magia, más control.

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

Observen el manejo de errores. En Golang no hay try-catch. Cada llamada a función se verifica para detectar errores. Esto no es un error, sino una característica: el código se vuelve predecible. En 5 años de trabajo, nunca he encontrado un puntero nulo inesperado en producción.

11:00 — Integración con gRPC

La siguiente etapa es agregar un endpoint gRPC para el panel de administración. En el desarrollo moderno en Go, gRPC se ha convertido en el estándar para servicios internos. Es más rápido que REST y genera clientes automáticamente.

Primero, describo el archivo proto:

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