Code review en Go: qué revisar y cómo dar retroalimentación a principiantes

Entrenador de Python en Línea para Principiantes

Aprende Python fácilmente sin sobrecargarte de teoría. Resuelve tareas prácticas con verificación automática, recibe pistas y escribe código directamente en el navegador, sin instalar nada.

Start Course

Code review en Go: qué revisar y cómo dar retroalimentación

El code review (revisión de código) no es solo una verificación formal antes de fusionar un pull request. Es una herramienta poderosa para mejorar la calidad del código, compartir conocimientos en el equipo y prevenir errores en etapas tempranas. Para los desarrolladores principiantes de Go, participar en una revisión puede parecer estresante: da miedo recibir observaciones o, por el contrario, pasar por alto un error crítico. En este artículo, analizaremos en qué aspectos fijarse al revisar código Go y cómo dar retroalimentación para que sea útil, no ofensiva.

\n\n

¿Por qué es importante el code review especialmente en Go?

El lenguaje Go fue creado con énfasis en la simplicidad, legibilidad y confiabilidad. Sin embargo, la simplicidad de la sintaxis no elimina la complejidad de la lógica. Los problemas típicos en proyectos Go incluyen: ignorar errores, manejo incorrecto de gorutinas y fugas de recursos. Un buen code review ayuda a identificar estos y otros problemas antes de que lleguen a producción.

\n\n

Qué revisar en código Go: lista de verificación para principiantes

Para que la revisión sea sistemática, use una lista de verificación. Estos son los puntos principales que debe revisar en cada pull request.

\n\n

1. Manejo de errores (error handling)

En Go, los errores son valores, no se pueden ignorar. Verifique que cada función que devuelve error lo maneje o lo pase explícitamente hacia arriba.

// Mal: ignoramos el error\nfile, _ := os.Open("config.yaml")\n\n// Bien: manejamos el error\nfile, err := os.Open("config.yaml")\nif err != nil {\n    log.Fatalf("cannot open config: %v", err)\n}\ndefer file.Close()

También verifique que los errores se envuelvan con fmt.Errorf("...: %w", err) para transmitir contexto, y no solo se registren y se ignoren.

\n\n

2. Nomenclatura y legibilidad

En Go se usan nombres cortos para variables (por ejemplo, r para reader, w para writer) y nombres largos para funciones exportadas. Verifique que:

Las funciones, tipos y variables exportadas tengan comentarios (que comiencen con el nombre de la entidad).
Los nombres de variables reflejen su propósito (no a, b, tmp).
No haya abreviaturas innecesarias (calc es mejor reemplazarlo por calculate).

\n\n

3. Trabajo con gorutinas y concurrencia

Las gorutinas son una herramienta poderosa pero peligrosa. Verifique:

Si existe un mecanismo de sincronización (canales, mutex) para datos compartidos.
Que no se creen gorutinas "fugitivas" (goroutine leak). Use contexto (context.Context) para cancelación.
Que la gorutina no se bloquee para siempre (deadlock).

// Ejemplo de trabajo seguro con gorutina\nfunc worker(ctx context.Context, jobs <-chan int, results chan<- int) {\n    for {\n        select {\n        case job, ok := <-jobs:\n            if !ok {\n                return\n            }\n            results <- job * 2\n        case <-ctx.Done():\n            return\n        }\n    }\n}

\n\n

4. Gestión de recursos (defer)

Verifique que todos los archivos abiertos, conexiones de red, transacciones de BD se cierren mediante defer. Esto debe hacerse inmediatamente después de abrir el recurso con éxito.

// Correcto: cerramos inmediatamente\nconn, err := net.Dial("tcp", "example.com:80")\nif err != nil {\n    return err\n}\ndefer conn.Close()

\n\n

5. Pruebas

Los principiantes a menudo olvidan las pruebas. Asegúrese de que se hayan escrito pruebas unitarias para la nueva lógica. Verifique:

Las pruebas cubren no solo el camino feliz (happy path), sino también los casos límite.
Si se usa t.Run para subpruebas.
Que no haya pruebas que dependan de recursos externos (BD, red) sin mocks.

\n\n