“Si funciona, no lo toques” — qué es, esencia del principio y riesgos

¿Qué es el principio “si funciona, no lo toques”?

“Si funciona, no lo toques” — es una regla empírica que advierte a los desarrolladores contra la realización de cambios en el código que funciona sin motivos suficientes. El principio se basa en estadísticas simples: la gran mayoría de los defectos se introducen durante la modificación del código existente.

El principio no es un dogma — es más bien una heurística que ayuda a tomar decisiones en condiciones de incertidumbre. Cuanto más compleja y enmarañada es la base de código, mayor es la probabilidad de que un cambio “inocente” rompa algo que nadie esperaba que se rompiera.

Según un estudio de Microsoft Corporation (2024), aproximadamente el 60% de todos los incidentes críticos en producción están relacionados con cambios recientes en el código que se hicieron con buenas intenciones pero no se probaron lo suficiente en condiciones de carga real.

Historia y origen del principio

El idioma “Si funciona, no lo toques” se remonta a la cultura de ingeniería estadounidense de mediados del siglo XX. El uso documentado más antiguo se atribuye a Bert Lance (1977), quien trabajaba en el Comité de Finanzas del Senado de EE. UU. y se oponía a la regulación excesiva.

En programación, el principio proviene de la ingeniería de hardware, donde reemplazar un chip que funcionaba por uno nuevo podía tener consecuencias impredecibles. En el contexto del software, este principio cobró especial relevancia con la creciente complejidad de los sistemas de software y la aparición del código heredado.

Curiosamente, en programación, el principio tiene su lado opuesto — “funciona, pero mejor no tocarlo” a menudo se convierte en una excusa para evitar la refactorización, lo que a largo plazo lleva a una acumulación crítica de deuda técnica. Según la consultora Thoughtworks (2023), alrededor del 40% de los proyectos enfrentan problemas graves debido al conservadurismo excesivo respecto a los cambios.

Cuándo aplicar el principio

El principio “si funciona, no lo toques” es especialmente relevante en situaciones donde el costo de un error supera el beneficio potencial de los cambios.

Proyectos heredados sin pruebas

En código heredado que no está cubierto por pruebas, cualquier cambio es una ruleta rusa. Si un desarrollador no puede verificar que un cambio no ha roto módulos adyacentes, la mejor estrategia es no tocar el código que funciona. La excepción son solo errores críticos o requisitos de seguridad.

Sistemas críticos

En sistemas donde el tiempo de inactividad es inaceptable o el costo de un error es enorme — software médico, aviónica, transacciones financieras — el principio “si funciona, no lo toques” es el estándar de facto. Cualquier cambio pasa por una aprobación y pruebas de múltiples etapas.

Plazos ajustados

Si el lanzamiento es mañana y el código funciona, no intentes mejorar su arquitectura. Cambia solo lo que afecta directamente la funcionalidad del lanzamiento. Aplaza la refactorización al siguiente sprint (pero no te olvides de ella).

Riesgos de seguir el principio

Seguir ciegamente el principio “si funciona, no lo toques” conlleva no menos riesgos que una refactorización interminable. Examinemos los principales peligros.

Acumulación de deuda técnica

Si cada desarrollador sigue este principio, la base de código se convierte rápidamente en un “pastel de capas” de soluciones obsoletas, parches y algoritmos subóptimos. Tarde o temprano, la deuda técnica se vuelve insostenible — cualquier cambio requiere semanas de análisis.

Oportunidades de optimización perdidas

A veces, un cambio que parece riesgoso en realidad mejora significativamente el rendimiento o la seguridad. El principio “si funciona, no lo toques” no debe bloquear cambios que aporten beneficios medibles — reducir costos de servidor, acelerar la carga de páginas, mejorar la seguridad.

Pérdida de competencias

Cuando un equipo no toca ciertas partes del código durante años, pierde la comprensión de cómo funcionan. El desarrollador clave se va — y el código se convierte en legado sin posibilidad de soporte. El principio debe aplicarse teniendo en cuenta el mantenimiento a largo plazo del proyecto.

El término medio: refactorización sin fanatismo

La estrategia óptima no es seguir el principio ciegamente, sino aplicarlo de manera consciente, teniendo en cuenta el contexto. La refactorización es necesaria, pero debe ser segura.

La regla del boy scout

La regla del boy scout en programación: “Deja el código más limpio de lo que lo encontraste.” Si un desarrollador realiza un cambio en un módulo, debe mejorar su estructura, pero dentro de límites razonables. No reescribir todo desde cero, sino al menos renombrar variables ilegibles y agregar comentarios.

Refactorización bajo la protección de pruebas

Las pruebas son la única forma de aplicar de manera segura el principio “si funciona, no lo toques”. Si el código está cubierto por pruebas, cualquier refactorización se vuelve predecible: el desarrollador cambia el código, ejecuta las pruebas y ve si algo se rompió. Sin pruebas — no lo toques. Con pruebas — refactoriza con confianza.

// Ejemplo: refactorización segura con cobertura de pruebas
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Código antiguo pero funcional
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Prueba que protege contra regresiones
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Este ejemplo demuestra el enfoque correcto: primero la prueba, luego la refactorización. Si la prueba pasa, el cambio es seguro. El principio “si funciona, no lo toques” se transforma en “si funciona bajo pruebas, refactoriza con confianza.”

Ejemplos reales de la práctica

Veamos escenarios reales donde el principio “si funciona, no lo toques” resultó tanto salvador como destructivo.

Caso salvador: problema similar al Y2K

Un desarrollador descubrió que el código de procesamiento de fechas usaba el formato DD/MM/AA en lugar de AAAA. El código funcionaba correctamente desde 2000 hasta 2025. A pesar del deseo de “arreglarlo”, dejó el código como estaba, limitándose a un comentario. En 2026, la empresa actualizó el sistema y la nueva solución manejaba correctamente los siglos. Un cambio prematuro habría roto la lógica funcional.

Caso destructivo: pérdida de datos por una “mejora”

Un ingeniero decidió “mejorar” el código antiguo pero funcional de importación de datos reemplazándolo con una biblioteca moderna. No tuvo en cuenta que la biblioteca antigua manejaba un caso límite específico que no estaba documentado. Después del lanzamiento — pérdida masiva de datos. El principio “si funciona, no lo toques” fue violado y el costo del error fue de dos semanas de trabajo del equipo para la recuperación.