Workaround en programación: qué es, cuáles existen y cómo funciona

¿Qué es un workaround en programación?

Workaround es un término coloquial para una solución de software que es funcionalmente correcta pero técnicamente subóptima. Dicho código funciona, pasa las pruebas e incluso llega a producción, pero leerlo provoca el deseo de reescribirlo todo desde cero. En el ámbito angloparlante se utilizan los términos workaround, kludge (kluge), hack o quick-and-dirty fix.

El término proviene de una metáfora doméstica: si se rompe la pata de una silla, se puede atar con cinta adhesiva — la silla vuelve a funcionar, pero la solución es temporal y poco estética. Lo mismo ocurre en programación: un error se corrige con hardcode, un workaround con timeout o una solución alternativa a través de una API no documentada. El código compila, la aplicación no se cae, pero la solución no puede considerarse de calidad.

Una diferencia importante: un bug es cuando el código no funciona; un workaround es cuando el código funciona pero está mal diseñado. Un workaround es siempre una decisión consciente del desarrollador: “Sé que esto es feo, pero ahora mismo resuelve el problema.”

Según Stripe (2024), los desarrolladores pasan un promedio de 17 horas semanales trabajando con deuda técnica y workarounds — casi la mitad de su tiempo laboral. Esto es una pérdida directa de productividad del equipo.

¿Cuándo y por qué aparecen los workarounds?

La primera y principal razón son los plazos ajustados. Cuando queda un día para el lanzamiento y un error crítico aún no está corregido, el equipo elige una solución rápida en lugar de la correcta. Hardcodear un valor, desactivar una comprobación, añadir sleep() — ejemplos clásicos de workarounds por plazo. Un desarrollador experimentado siempre marca estos lugares con TODO o FIXME.

La segunda razón es la incompatibilidad de API. Una biblioteca o framework de terceros se comporta de manera diferente a lo documentado. El framework no exporta la clase necesaria, un método está marcado como obsoleto y no hay alternativa. El desarrollador se ve obligado a usar reflexión, API internas o una solución alternativa. En Java, esto puede ser acceso mediante setAccessible(true); en Swift — @objc y performSelector.

La tercera razón es el código heredado. Un desarrollador hereda un proyecto escrito hace 5-10 años en una versión obsoleta del framework. No hay tiempo ni presupuesto para reescribir todo el módulo, por lo que la nueva funcionalidad se “pega” al código antiguo mediante workarounds. Gradualmente se acumulan tantas capas que el módulo se convierte en una “bola de barro” (big ball of mud).

La cuarta razón es la falta de pruebas. La refactorización sin pruebas es peligrosa: cambiar la arquitectura puede romper la funcionalidad existente. Cuando no hay pruebas, el desarrollador prefiere añadir un workaround sobre el código que funciona antes que arriesgar la estabilidad. Según Google Testing Blog (2024), los equipos sin pruebas tienen 3 veces más probabilidades de usar soluciones workaround.

Tipos de workarounds

La clasificación de workarounds ayuda al equipo a entender qué tipo de deuda técnica tiene y a elegir la estrategia de eliminación correcta. Veamos los tipos principales.

Hardcode — el tipo más común. En lugar de configuración, recurso o parámetro, se utiliza un valor fijo en el código. Ejemplo: una URL de servidor hardcodeada, un timeout de 5 segundos, un tamaño de fuente de 16pt. El hardcode hace que el código no sea escalable y requiera recompilación ante cualquier cambio.

Copiar y pegar — duplicar un fragmento de código con cambios menores en lugar de extraer la lógica común. Síntoma clásico: hay 3 métodos similares en el proyecto que se diferencian en una línea. Copiar y pegar acelera la escritura del código en el momento de la tarea, pero ralentiza 10 veces su mantenimiento en el futuro — la corrección debe aplicarse en 3 lugares en lugar de uno.

Try-catch vacío — un bloque catch que no hace nada o solo registra el error sin procesarlo. Este workaround “silencia” la excepción pero no resuelve su causa. La aplicación sigue funcionando, pero los datos pueden dañarse y el usuario puede no recibir retroalimentación.

Sleep en el código — Thread.sleep(500) o DispatchQueue.main.asyncAfter para esperar cuando debería haber un evento o callback. Este código no es fiable: en un dispositivo lento, 500 ms pueden no ser suficientes; en uno rápido, la pausa es innecesaria. Utilice CountDownLatch, Semaphore o async/await con tiempos adecuados.

Banderas de compatibilidad — cascadas if-else que verifican la versión del SO, el modelo del dispositivo o la disponibilidad de una funcionalidad. Cuando hay más de 3-4 banderas, el código se convierte en espagueti. La solución es el patrón Strategy o Feature Flags mediante configuración.

Workaround vs deuda técnica

Muchos desarrolladores confunden workaround y deuda técnica. La diferencia está en la escala y la conciencia. Un workaround es una solución local y concreta (un método, una clase). La deuda técnica es un problema sistémico que afecta a la arquitectura de un módulo o de toda la aplicación.

La metáfora de Ward Cunningham (creador del término Deuda Técnica): la deuda técnica es como pedir un préstamo bancario. Tomas dinero ahora para construir la casa más rápido, pero luego pagas intereses. Un workaround es como clavar un clavo con un martillo en lugar de un taladro eléctrico: el trabajo se hace, pero de forma menos eficiente.

Un workaround no crea deuda técnica. Pero 50 workarounds en un módulo = deuda arquitectónica. Por lo tanto, regla del equipo: cada workaround se registra en el code review o en el task tracker, y el equipo revisa regularmente (una vez por sprint) las soluciones workaround acumuladas.

Según Spotify Engineering (2023), los equipos que realizan un seguimiento de los workarounds en el código (mediante una etiqueta TODO especial o una anotación personalizada) reducen el tiempo de refactorización en un 30% — porque no pierden horas buscando lugares problemáticos.

Cómo eliminar los workarounds

El primer paso es el inventario. Busque en la base de código palabras clave: TODO, FIXME, HACK, WORKAROUND, KLUDGE. Los IDE modernos las resaltan con un color diferente. GitHub también muestra TODO en la interfaz de Pull Request. Elabore una lista de todos los workarounds con prioridad.

El segundo paso es la priorización. No todos los workarounds deben corregirse de inmediato. Prioridad = frecuencia de cambios en el archivo × criticidad. Si un archivo cambia 2 veces al año, el workaround puede esperar. Si un módulo se toca en cada sprint — el workaround debe corregirse primero.

El tercer paso es la refactorización con pruebas. Nunca refactorice un workaround sin pruebas. Primero escriba una prueba que verifique el comportamiento actual (con el workaround), luego refactorice, luego asegúrese de que la prueba pase. Sin esto, la refactorización de un workaround puede romper la funcionalidad para la que fue escrito.

// Before: URL hardcodeada workaround
fun getApiUrl(): String {
    return "https://api.example.com/v2"
}

// After: configuración via BuildConfig
fun getApiUrl(): String {
    return BuildConfig.API_BASE_URL
}

El cuarto paso es la automatización. Configure un linter que prohíba ciertos patrones de workaround. Por ejemplo, Detekt para Kotlin puede verificar la ausencia de Thread.sleep() en código de producción, ESLint puede prohibir console.log en el proyecto. Esto evita la aparición de nuevos workarounds del mismo tipo.

¿Cuándo está justificado un workaround?

A pesar de la connotación negativa del término, un workaround puede ser una solución justificada. La condición principal: el workaround es temporal, está explícitamente marcado y tiene un plan de reemplazo. En el código de producción de cada proyecto grande hay cientos de workarounds justificados.

Situación 1: hotfix en producción. Un error crítico afecta a todos los usuarios. El equipo necesita una corrección en una hora. El enfoque correcto: corregir el error de cualquier manera posible, desplegar el hotfix. Luego, al día siguiente, escribir la solución adecuada y cerrar el ticket. Un hotfix es un workaround justificado si no vive más de 48 horas.

Situación 2: esperar una nueva versión de la biblioteca. Un framework contiene un error corregido en master, pero el lanzamiento será en 2 semanas. En lugar de escribir un código de solución alternativo complejo, el equipo añade un workaround con la nota “REMOVE after library 3.2.” Cuando se lanza la 3.2, se elimina el workaround.

Situación 3: cierre de una startup o MVP. En la etapa de MVP, la velocidad es más importante que la arquitectura. Los workarounds al inicio son normales. El problema surge cuando la startup no se convierte en producto, pero los workarounds permanecen. Recomendación: después de una ronda de financiación, asigne un sprint para pagar la deuda técnica crítica.

El principio principal: “El código heredado es código sin pruebas” (Michael Feathers). Si un workaround está cubierto por una prueba y está explícitamente documentado — es manejable. Si ha estado colgado sin comentarios durante 2 años en un módulo olvidado — ya no es un workaround, sino un problema arquitectónico.