Refactorización de código Go: cuándo y cómo — guía para la limpieza y velocidad

Refactorización de código Go: cuándo y cómo no romper el proyecto

¿Alguna vez ha abierto su antiguo código Go y ha sentido una ligera nostalgia? Variables llamadas a y b, funciones que ocupan toda la pantalla, y el bucle principal de procesamiento de solicitudes que recuerda al laberinto del Minotauro. ¿Le suena familiar? Bienvenido al mundo donde la refactorización no es un lujo, sino una necesidad.

Go es famoso por su simplicidad y velocidad de compilación, pero eso no significa que el código se escriba solo de forma perfecta. Tarde o temprano, todo desarrollador se enfrenta a la pregunta: «¿Cuándo es hora de poner orden?». En este artículo, analizaremos cómo hacer refactorización de código Go sin miedo y sin reproches, con ejemplos reales y consejos de profesionales.

Cuándo es necesaria la refactorización de código Go: banderas rojas

La refactorización no se trata de «reescribir todo desde cero». Se trata de mejorar la estructura interna sin cambiar el comportamiento externo. Estas son señales claras de que es hora de tomar las herramientas:

\n
• El código huele (code smell): duplicación, funciones largas, números mágicos.
\n
• Es difícil añadir nuevas funciones: cada parche rompe pruebas antiguas.
\n
• Pruebas lentas: si las pruebas unitarias tardan más de 10 segundos, la estructura cojea.
\n
• Muchos if/else o switch: especialmente cuando aparecen nuevos tipos.
\n
• Anidamiento salvaje: if err != nil { if ... } — un infierno de depuración.
\n

En Go es especialmente importante vigilar el manejo de errores y las interfaces. Si se sorprende escribiendo interface{} donde se necesita un tipo concreto, es una señal de alerta.

Etapas de la refactorización: del plan al commit

La refactorización sin estrategia es un camino al caos. Siga un algoritmo simple:

\n
1. Comprenda qué está mal exactamente. Escriba una lista de problemas: duplicación, complejidad, secciones lentas.
\n
2. Escriba pruebas. Sin pruebas, la refactorización es una ruleta rusa. Use go test y cubra las rutas críticas.
\n
3. Dé pasos pequeños. Un bloque lógico a la vez. Commit después de cada cambio exitoso.
\n
4. Ejecute pruebas y benchmarks. Asegúrese de que el rendimiento no haya disminuido.
\n
5. Revise el code review. Una mirada fresca de un colega encontrará lo que usted pasó por alto.
\n

Ejemplos prácticos de refactorización de código Go

La teoría está bien, pero veamos código real. A continuación, tres situaciones típicas y sus soluciones.

1. Eliminando la duplicación con funciones

Supongamos que tiene código que analiza la configuración y verifica errores de la misma manera:

// Mal: duplicación de la lógica de verificación\nfunc loadConfig(path string) (*Config, error) {\n    data, err := os.ReadFile(path)\n    if err != nil {\n        return nil, fmt.Errorf("read config: %w", err)\n    }\n    var cfg Config\n    err = json.Unmarshal(data, &cfg)\n    if err != nil {\n        return nil, fmt.Errorf("parse config: %w", err)\n    }\n    return &cfg, nil\n}\n\nfunc loadSecrets(path string) (*Secrets, error) {\n    data, err := os.ReadFile(path)\n    if err != nil {\n        return nil, fmt.Errorf("read secrets: %w", err)\n    }\n    var sec Secrets\n    err = json.Unmarshal(data, &sec)\n    if err != nil {\n        return nil, fmt.Errorf("parse secrets: %w", err)\n    }\n    return &sec, nil\n}

Solución: extraemos la lógica común en una función utilitaria.

// Bien: método único para leer y analizar JSON\nfunc readJSON[T any](path string) (*T, error) {\n    data, err := os.ReadFile(path)\n    if err != nil {\n        return nil, fmt.Errorf("read file %s: %w", path, err)\n    }\n    var result T\n    err = json.Unmarshal(data, &result)\n    if err != nil {\n        return nil, fmt.Errorf("unmarshal %s: %w", path, err)\n    }\n    return &result, nil\n}\n\n// Ahora