Refactorizar sin miedo: cambiar un tipo y dejar que el compilador te lleve

Pregunta a alguien que lleve un par de años escribiendo Elm qué es lo que más echa de menos cuando vuelve a otro lenguaje y casi nunca contestará la inferencia de tipos, ni la ausencia de excepciones, ni los mensajes de error. Contestará que echa de menos poder cambiar de opinión. En un proyecto de tamaño mediano escrito sin garantías, modificar una decisión estructural tomada hace ocho meses es una operación cuyo coste nadie sabe estimar: hay que encontrar todos los sitios afectados con búsquedas de texto que dan falsos positivos y omiten los usos indirectos, hay que confiar en que la suite de pruebas cubra las ramas que se han roto, y hay que asumir que algo va a llegar a producción sin que nadie lo haya visto. Esa incertidumbre tiene un efecto que no aparece en ninguna métrica y que degrada los sistemas más que cualquier otra cosa: el código deja de mejorar. Las decisiones malas se rodean en vez de corregirse, los tipos se quedan como estaban y se añaden capas encima. Elm ataca ese problema por la raíz, y esta lección explica el mecanismo exacto: convertir un cambio de tipo en una lista de tareas completa, finita y escrita por la máquina.

El bucle: cambia un tipo y sigue los errores

El método es tan simple que cuesta creer que baste. Se modifica la declaración de tipo que representa la nueva verdad sobre el dominio, se ejecuta elm make, se lee el primer error, se arregla, y se vuelve a compilar. No hay fase de análisis previo, no hay búsqueda de usos, no hay lista escrita a mano de sitios pendientes: la lista es la salida del compilador, y termina cuando la compilación pasa. El cambio de hábito que exige es pequeño pero cuesta: hay que resistirse a arreglar el código antes de romperlo, y hay que empezar por el tipo aunque en ese instante nada compile.

-- Antes: un chiste solo podia estar en dos estados
type Estado
    = Borrador
    | Publicado


-- Despues: el dominio crece y aparece un tercer estado
type Estado
    = Borrador
    | Publicado
    | Archivado Posix


-- Cada case sobre Estado deja de compilar hasta cubrir el nuevo constructor
etiqueta : Estado -> String
etiqueta estado =
    case estado of
        Borrador ->
            "Sin publicar"

        Publicado ->
            "Visible"

        Archivado fecha ->
            "Archivado el " ++ formatearFecha fecha

El segundo refactor canónico es el campo nuevo en un record, y su comportamiento difiere del anterior de una forma instructiva. Añadir un campo rompe todos los sitios donde se construye el record completo, porque el literal deja de tener la forma exigida, pero no rompe los sitios donde solo se lee otro campo ni los que actualizan parcialmente. Es exactamente el comportamiento deseado: el compilador te lleva a donde hay una decisión que tomar, que es decidir qué valor tiene el campo nuevo en cada punto de creación, y te deja en paz donde no hay ninguna.

# El bucle completo, sin lista de tareas escrita a mano
elm make src/Main.elm --output=/dev/null

# 1. Cambia el tipo
# 2. Compila y lee el PRIMER error
# 3. Arregla solo ese
# 4. Vuelve a compilar
# ... hasta que la compilacion pase: entonces has terminado

El tercer refactor canónico es el cambio de firma de una función central, y es el que mejor muestra el carácter transitivo del método. Modificar el tipo de retorno de una función que usan veinte sitios no produce veinte errores independientes: produce una onda que avanza por el grafo de llamadas, porque cada sitio corregido puede a su vez cambiar su propio tipo y romper a quien lo llamaba. El bucle sigue funcionando igual, pero conviene saber que el número de errores puede crecer antes de empezar a decrecer, y que ese aumento no es señal de que el refactor se esté descontrolando sino de que la onda todavía está propagándose.

-- Antes: la funcion prometia siempre un resultado
buscar : String -> List Chiste -> Chiste


-- Despues: el dominio admite que no haya ninguno
buscar : String -> List Chiste -> Maybe Chiste

Por qué la lista está completa

La confianza en este método no descansa en la costumbre sino en cuatro propiedades del lenguaje que se refuerzan entre sí, y conviene enunciarlas porque explican por qué el mismo bucle aplicado a otro lenguaje con tipos estáticos da un resultado más débil. La primera es que no existe ninguna escotilla de tipado: no hay un tipo comodín que absorba cualquier valor, no hay conversión insegura y no hay forma de decirle al compilador que confíe. Todo dato que entra en el programa pasa por un decodificador que declara su forma, de modo que no queda ningún punto opaco donde un tipo pueda cambiar sin que nadie se entere.

La segunda es la exhaustividad obligatoria del case, que convierte cada punto de decisión sobre una unión en un sitio que el compilador vigila. La tercera es la ausencia de despacho dinámico: como no existen métodos que se resuelvan en tiempo de ejecución, cada aplicación de función es un sitio estáticamente determinado y no hay implementaciones alternativas que se escapen del análisis. Y la cuarta es que el sistema de tipos es sólido, lo cual significa que no admite programas cuyos tipos mienten. La conjunción de las cuatro produce la propiedad que hace útil el método: si el proyecto compila después del cambio, no queda ningún sitio afectado sin revisar.

Vale la pena contrastar esto con lo que ocurre al aplicar el mismo bucle en un lenguaje con tipos estáticos pero con escotillas. Allí el compilador también enumera sitios, pero la lista es incompleta por construcción: cada conversión forzada, cada valor de tipo comodín, cada dato que entró sin validarse desde una respuesta de red y cada punto de despacho dinámico es un lugar por donde el cambio se cuela sin protestar. El resultado es peor que no tener ayuda, porque la lista parece completa y no lo es, y la confianza que genera se paga en producción. La diferencia entre ambas situaciones no es de grado sino de naturaleza: una lista con falsos negativos desconocidos no permite dar por terminado el trabajo.

flowchart LR
T[Cambiar la declaracion de tipo] --> C[elm make]
C --> E[Primer error con sitio exacto]
E --> F[Arreglar solo ese sitio]
F --> C
C --> OK[Compila: refactor completo]
style T fill:#cba6f7,color:#11111b
style E fill:#f9e2af,color:#11111b
style OK fill:#a6e3a1,color:#11111b

Lo que el compilador no ve

La honestidad exige delimitar la garantía, porque la confianza mal calibrada es peor que la desconfianza. El compilador detecta cambios de forma, no cambios de significado. Si dos parámetros contiguos tienen el mismo tipo y los intercambias, la firma sigue encajando y ninguna llamada se rompe, aunque el programa haya empezado a mentir. Si un campo llamado precio pasa de expresar euros a expresar céntimos, el tipo sigue siendo el mismo y no hay un solo error. Si un decodificador espera un campo que el servidor ha dejado de enviar, la compilación es perfecta y el fallo aparece en tiempo de ejecución como un valor de error que alguien tendrá que tratar. Y si un puerto cambia la forma del dato que envía desde JavaScript, la frontera no compila esa parte.

-- Peligro: dos Int contiguos con significados distintos
mover : Int -> Int -> Posicion -> Posicion


-- Remedio: tipos opacos que el compilador no puede confundir
type Fila
    = Fila Int


type Columna
    = Columna Int


mover : Fila -> Columna -> Posicion -> Posicion

El remedio es de modelado y no de disciplina: cuando un cambio importante resulta invisible al compilador, casi siempre es porque el tipo era demasiado ancho. Envolver un entero en un tipo propio, separar dos unidades que compartían representación o convertir una cadena en una unión de casos válidos son operaciones que cuestan unas líneas y que trasladan al sistema de tipos una distinción que antes solo vivía en la cabeza del equipo. A partir de ese momento, el mismo error que era silencioso pasa a formar parte de la lista que el compilador redacta.

Existe además una técnica deliberada para forzar la visibilidad de un cambio semántico cuando el tipo no puede estrecharse: renombrar. Si vas a cambiar el significado de un campo o de una función sin cambiar su tipo, cámbiale también el nombre en la misma operación. El renombrado rompe todos los usos, el compilador te lleva a cada uno y en cada visita tomas la decisión con el contexto delante. Es un uso instrumental del sistema de tipos que parece un rodeo y que en la práctica convierte el refactor más peligroso que existe, el que compila igual antes y después, en uno del mismo tipo que los demás.