Sesiones de Par y Mob para Equipos Go

Patrones de transferencia de conocimiento para modismos y concurrencia.

Los modismos de Go se aprenden a través de bucles de retroalimentación sobre código real.

El emparejamiento y el mobbing estructurados comprimen meses de prueba y error en sesiones enfocadas que también difunden la cultura de revisión.

Resumen

El emparejamiento y el mobbing son formatos deliberados para compartir hábitos de la cadena de herramientas, patrones de manejo de errores y juicio de revisión de concurrencia.

Complementan las rutas de lectura y las listas de verificación con la explicación en vivo de por qué un revisor bloquearía un PR.

Las sesiones cortas con agendas claras superan el intercambio de pantalla no estructurado.

Receta

Tarjeta de referencia rápida - lista para copiar y pegar.

## Par de incorporación de 90 minutos (plantilla)
 
1. (15m) El navegador recorre la estructura del módulo + README de CI
2. (25m) El conductor soluciona un problema de golangci-lint con la orientación del navegador
3. (25m) Lectura conjunta de una ruta de código concurrente; ejecuta go test -race
4. (15m) Debrief: tres modismos para aplicar + un PR para abrir antes de la próxima sesión
5. (10m) Programa la próxima sesión + asigna enlace de prelectura

Cuándo usar esto:

• Las primeras dos semanas de incorporación a Go para empleados experimentados
• Antes del primer PR de un ingeniero centrado en la concurrencia
• Después de un incidente para reproducir la línea de tiempo y las pruebas
• Cuando los comentarios de revisión repiten la misma brecha de modismos en varios autores

Ejemplo de Trabajo

Un equipo ejecuta un mob de concurrencia semanal sobre un error en staging: recuento elevado de gorutinas después del despliegue.

// El mob examina este patrón juntos - el conductor comparte pantalla
func (s *Service) poll(ctx context.Context) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-time.After(time.Second):
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

// Resultado de refactorización al que apunta el mob - ticker con defer Stop
func (s *Service) poll(ctx context.Context) error {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop()
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()
        case <-ticker.C:
            if err := s.tick(ctx); err != nil {
                return err
            }
        }
    }
}

Lo que esto demuestra:

• time.After en bucles asigna temporizadores; la solución idiomática usa NewTicker y Stop.
• El mob lee primero las métricas de producción, luego el código, luego escribe una prueba de regresión.
• El navegador pide al conductor que ejecute go test -race antes de fusionar la corrección.
• Las notas de la sesión enlazan al PR y actualizan un documento de trampas del equipo.

Inmersión Profunda

Cómo Funciona

• El conductor tiene el teclado; el navegador hace preguntas, detecta errores omitidos y cita los estándares del equipo.
• El mob se extiende a 3 o más personas con un conductor rotando en un temporizador; es mejor para incidentes y análisis de diseño.
• Las sesiones deben terminar con artefactos: enlace de PR, actualización de lista de verificación o viñeta de ADR, no solo acuerdo verbal.

Tipos de Sesión

Notas de Go

// Ejercicio de emparejamiento: esqueleto de subprueba basado en tabla que esperan los revisores
func TestLimiter(t *testing.T) {
    cases := []struct {
        name string
        n    int
        want int
    }{
        {"zero", 0, 0},
        {"one", 1, 1},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := Limiter(tc.n); got != tc.want {
                t.Fatalf("got %d want %d", got, tc.want)
            }
        })
    }
}

Usa ejercicios como este cuando la retroalimentación de la revisión diga "añadir casos" pero el autor no haya visto pruebas ejemplares en tu repositorio.

Reglas de Facilitación

• Rota los roles cada 20-30 minutos en los mobs.
• Silencia los teléfonos; una conversación a la vez.
• Estaciona refactorizaciones no relacionadas en una lista de "más tarde" visible para el grupo.
• Prefiere tareas del repositorio sobre ejercicios sintéticos después de la primera semana para que las importaciones y la CI coincidan con la realidad.

Trampas

• Mob sin límites y sin agenda - las sesiones decaen en observación pasiva. Solución: publica una agenda de tres puntos antes de la invitación del calendario.
• Siempre el mismo senior navega - crea una cultura de revisión de punto único. Solución: rota los navegadores mensualmente.
• Omitir -race durante los pares de concurrencia - los nuevos empleados piensan que las pruebas verdes significan concurrencia segura. Solución: haz que la ejecución de race sea un criterio de salida de la sesión.
• Sin seguimiento escrito - las ideas mueren cuando las personas cambian de tarea. Solución: nota de debrief de dos minutos en el ticket o wiki.
• Emparejar solo a juniors - los seniors también necesitan emparejarse al tocar dominios desconocidos (operadores, WASM). Solución: programa pares inter-niveles en nuevas pilas.
• Grabar sin consentimiento - viola la política o la comodidad. Solución: pregunta explícitamente; por defecto, solo notas escritas.

Alternativas

Preguntas Frecuentes

Relacionado

• Incorporación de Especialistas Go - dónde encaja el emparejamiento en las capas de rampa
• Conceptos Básicos de Incorporación de Equipos - ejemplo de agenda de emparejamiento 9
• Lista de Verificación de Incorporación de Expertos Go (30/60/90) - filas de evidencia de emparejamiento
• Cultura de Revisión de Código para Go - normas que los pares deben enseñar
• Ruta de Lectura de Go Efectivo - columna vertebral de prelectura entre sesiones

Versiones de Stack: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC, go fix modernizers - verifica el parche en la compilación), chi (última - verifica en la compilación), gin (última - verifica en la compilación), echo (última - verifica en la compilación), google.golang.org/grpc (última - verifica en la compilación), sigs.k8s.io/controller-runtime (última - verifica en la compilación), kubebuilder (última - verifica en la compilación), tinygo (última - verifica objetivos de placa en la compilación), wazero (última - verifica en la compilación) y golangci-lint (última - verifica el conjunto de linters en la compilación).