Hay una categoría de refactorización que los equipos hacen constantemente, de la que se benefician de inmediato y que casi nunca nombran.
Es el trabajo que haces justo antes de tocar el archivo que da miedo. La solicitud de una funcionalidad te empuja al módulo desordenado. Llega el incidente, y el bug está escondido en algún punto dentro de un método que parece tener su propio sistema meteorológico.
No estás rediseñando el sistema. No estás introduciendo una nueva abstracción. No estás “mejorando” nada de forma ingeniosa.
Solo estás haciendo el código lo bastante legible como para poder trabajar.
Empecé a llamar a esto refactorización Tipo 0.
La refactorización Tipo 0 es una limpieza preparatoria que preserva el comportamiento y vuelve el código más fácil de razonar antes de hacer refactorizaciones arquitectónicas, trabajo de rendimiento o trabajo de funcionalidades.
Es el paso de “secar el suelo antes de remodelar la cocina”. La mayoría de los equipos ya lo hacen de manera informal. Nombrarlo lo convierte en una herramienta compartida.
La verdadera razón por la que existe el Tipo 0: los humanos tienen un presupuesto de memoria de trabajo
Esta es la verdad cruda detrás de la idea:
Mi cerebro (y el tuyo) no está hecho para depurar de forma fiable un método de 2000 líneas bajo presión de tiempo.
Eso no es un defecto personal. Es simplemente cómo funciona la cognición.
Depurar te pide sostener, al mismo tiempo:
- la ruta de ejecución actual
- el estado relevante
- lo que realmente significa cada variable
- el conjunto de posibles ramificaciones
- las consecuencias de “si pasa esto, entonces…”
En código pequeño, esto es manejable.
En código grande con alta complejidad ciclomática, se convierte en adivinación probabilística. Aún puedes tener suerte, pero es caro y arriesgado, sobre todo durante un hotfix.
El Tipo 0 es una respuesta práctica: es la forma de comprar claridad rápido sin asumir el costo y el riesgo de una “refactorización real”.
Por qué se llama “Tipo 0”
El nombre no salió de una gran teoría. Salió de un momento de mucha presión.
Estaba trabajando en un hotfix. El bug estaba enterrado dentro de un método que era, en la práctica, su propio pequeño universo: unas 2000 líneas.
El bug no era difícil conceptualmente. El método sí.
Cada “qué pasa si…” se ramificaba en diez preguntas más, y la ramificación no era de la útil. Era complejidad incidental: ruido, repetición, nombres poco claros y una estructura que no coincidía con el modelo mental que necesitas para depurar.
Lo que necesitaba no era perfección. Necesitaba depurabilidad:
- menos ramificaciones por pantalla
- “pasos” más claros con nombres
- menos ruido
- menos tiempo releyendo lo que acababa de leer
Pero la presión de tiempo no daba para una refactorización mayor ni para un “rediseño idiomático”. Hacerlo de forma responsable habría sido medio día (o más), incluyendo pruebas manuales. En una ventana de hotfix, eso no es disciplina; es apostar.
Así que le pedí a un LLM que sugiriera oportunidades de refactorización para la clase y ese método, sin decirle por qué.
Volvió con una lista de cuatro “tipos” de refactorización. Todos sensatos. Todos aplicables. Todos demasiado caros para ese momento.
Entonces hizo la pregunta cortés:
“¿Debería empezar con el Tipo 1?”
Ahí fue cuando respondí:
“No. Empecemos con el Tipo 0.”
Y definí el Tipo 0 sobre la marcha: un conjunto acotado y mecánico de cambios que reducen la complejidad y aumentan la legibilidad sin cambiar el comportamiento ni la arquitectura.
El método se volvió navegable. Mi cerebro pudo seguir de nuevo la ejecución. Encontré el bug, lo arreglé y desplegué sin daños colaterales.
Por eso me gusta el nombre Tipo 0: es la refactorización que haces antes de los tipos de “refactorización real”, especialmente cuando estás bajo presión y necesitas una forma segura de crear claridad rápido.
El problema que resuelve el Tipo 0
La mayoría de los consejos sobre refactorización dan por hecho que ya puedes ver el diseño.
En bases de código reales:
- los métodos son largos y de múltiples propósitos
- expresiones repetidas y complejidad incidental esconden la intención
- las variables son crípticas (
$e,$tmp,$res) - el código muerto y los imports sin usar crean ruido mental
- la “forma” del código está tan desordenada que incluso los cambios pequeños se sienten arriesgados
Cuando intentas una “refactorización real” sobre todo eso (límites, patrones, mover responsabilidades), apilas incertidumbre sobre incertidumbre:
- no puedes saber con facilidad qué comportamiento estás preservando
- no puedes predecir el radio de impacto
- las revisiones degeneran en debates subjetivos
- la gente empieza a tener miedo de tocar las cosas, y el desorden se acumula
El Tipo 0 es la forma de bajar primero la carga cognitiva. Crea una base estable donde el trabajo más profundo puede ocurrir de forma segura.
Recurre al Tipo 0 cuando…
El Tipo 0 es más valioso cuando:
- debes depurar rápido (hotfixes, incidentes) y el código es demasiado grande o ramificado para razonarlo con seguridad
- te sientes “perdido en el método” y sigues releyendo la misma sección porque la estructura no ayuda a tu memoria de trabajo
- el código es correcto pero ilegible, y no puedes permitirte “limpiar la lógica”, solo exponerla
- quieres reducir el riesgo antes de un trabajo más profundo (sabes que vas a refactorizar después, pero primero necesitas un mapa claro del comportamiento actual)
- quieres convertir el conocimiento tribal en una estructura legible para que la depuración no dependa de una sola persona
El Tipo 0 no es un lujo. En estos casos suele ser la forma más rápida de recuperar el control.
Una definición que puedes usar en tu equipo
La refactorización Tipo 0 es un conjunto de micro-refactorizaciones que mejoran la legibilidad y la mantenibilidad sin cambiar el comportamiento ni la arquitectura.
Es deliberadamente acotada. Las restricciones son la característica.
El Tipo 0 consta de cuatro subpatrones obligatorios:
- 0a. Extracción de métodos
- 0b. Concisión
- 0c. Empatía (legibilidad pura)
- 0d. Eliminación de código muerto
Y sigue tres reglas estrictas:
- Sin cambios de comportamiento
- Sin cambios arquitectónicos
- Sin mejoras “ingeniosas” más allá de los cuatro patrones
Si violas esas reglas, ya no estás haciendo Tipo 0: te has movido a otra categoría de trabajo, y eso requiere una coordinación distinta, un rigor de revisión distinto y, a menudo, una estrategia de pruebas distinta.
¿Por qué nombrarlo siquiera?
Porque nombrarlo cambia cómo se coordinan los equipos.
- “Solo estoy haciendo Tipo 0 en este PR” les dice a los revisores qué buscar: preservación del comportamiento y legibilidad, no debates de arquitectura.
- “Necesitamos Tipo 0 antes de refactorizar esto” es una admisión honesta de que el código aún no está listo para un cambio más profundo.
- “Hagamos el Tipo 0 como Paso 0” crea un pequeño ritual que evita que construyas sobre el caos.
Los cuatro subpatrones
0a. Extracción de métodos (el fundamento)
Objetivo: dividir métodos grandes en otros pequeños y enfocados para que un humano pueda leer la intención de forma lineal.
Reglas prácticas:
- divide los métodos que son demasiado largos para sostenerlos en la memoria de trabajo
- cada método extraído debería hacer una sola cosa y tener un nombre descriptivo
- extrae pasos significativos, no fragmentos arbitrarios de N líneas
Por qué funciona (especialmente para depurar):
- los métodos más pequeños crean etiquetas para la ruta de ejecución
- un scroll de 2000 líneas se convierte en un método de orquestación corto que puedes recorrer mentalmente
- puedes poner breakpoints en los límites semánticos (“validar entrada”, “construir consulta”, “aplicar filtros”) en lugar de andar a la caza
0b. Concisión (reduce la complejidad incidental)
Objetivo: eliminar el ruido visual para que la intención resalte.
Ejemplos:
- extrae expresiones repetidas a variables locales
- extrae contextos de log repetidos / cadenas clave / fragmentos de URL a variables
- prefiere las características del lenguaje que comunican la intención de forma directa
- simplifica la interpolación demasiado verbosa
Por qué funciona:
- reduce la carga cognitiva
- hace los diffs más pequeños y los cambios más seguros
- evita la deriva por copiar y pegar
0c. Empatía (legibilidad pura)
Objetivo: escribir para el siguiente humano, no para el compilador.
Empatía significa:
- usar nombres de variables descriptivos (evita
$e,$d,$tmpsalvo que sean realmente obvios) - mantener una terminología consistente en todo un módulo
- renombrar los nombres engañosos
- hacer que el código se documente a sí mismo
Prueba de fuego:
Si alguien lee esto a las 2 de la madrugada durante un incidente, ¿le ayudará a mantener la ruta de ejecución en la cabeza?
0d. Eliminación de código muerto (quitar las mentiras)
Objetivo: borrar todo lo que finge importar pero no importa.
Ejemplos:
- métodos privados sin usar
- imports sin usar
- enfoques viejos comentados
- helpers obsoletos que nadie llama
Por qué funciona:
- menos código significa menos cosas que malinterpretar
- los resultados de búsqueda se vuelven confiables
Lo que el Tipo 0 no es
El Tipo 0 no es:
- cambiar los límites de los servicios
- introducir nuevas abstracciones o patrones
- rearquitecturar un flujo de trabajo
- reemplazar librerías
- reordenar responsabilidades entre capas
- “arreglar” lógica que sospechas que está mal (a menos que declares explícitamente el cambio de comportamiento y lo pruebes)
Si te sorprendes diciendo:
- “Ya que estoy aquí, hagamos también…”
- “Esto quedaría mejor si…”
- “Probablemente deberíamos rediseñar…”
Puede que estés saliendo del Tipo 0. Eso no es malo de por sí, pero debería ser intencional.
La promesa central: preservación del comportamiento (y cómo mantenerla cierta)
El Tipo 0 solo funciona si los equipos confían en la promesa.
Y sí, tienes razón en sospechar: la extracción de métodos puede cambiar el comportamiento por accidente (early returns, alcance de variables, orden de evaluación, comportamiento de excepciones).
Así que el Tipo 0 necesita una disciplina que lo mantenga honesto:
Extrae tal cual, luego renombra y limpia.
- Primera pasada: mueve el código a métodos sin cambiar la lógica
- Segunda pasada: aplica concisión + empatía
- Tercera pasada: elimina el código muerto
Salvaguardas prácticas:
- no reordenes las comprobaciones de condiciones “por legibilidad”
- no reemplaces lógica por lógica “equivalente” a menos que estés fuera del Tipo 0
- ten cuidado con las variables que antes estaban en un alcance compartido
- trata las diferencias “pequeñas” en el flujo de control como diferencias reales
Y si tienes cualquier red de seguridad, por fina que sea:
- ejecuta una prueba enfocada
- reproduce el escenario que falla
- valida la única ruta que estás tocando
El Tipo 0 trata de ser rápido, pero rápido reduciendo la complejidad cognitiva, no rápido saltándose la seguridad.
El Tipo 0 como ritual de equipo repetible
1) Decide el alcance (ayuda ponerle un límite de tiempo)
Ejemplos:
- “Aplica Tipo 0 a la ruta caliente antes de depurar.”
- “Aplica Tipo 0 solo a la ruta que toca este arreglo de bug.”
2) Identifica la “columna vertebral” del código
Encuentra el método (o métodos) de entrada y los puntos de ramificación. Convierte esa columna vertebral en una narrativa legible mediante extracción.
3) Aplica los cuatro subpatrones en orden
Extracción de métodos → concisión → empatía → eliminación de código muerto.
4) Mantén una “checklist de Tipo 0” en tu PR
- Sin cambios de comportamiento (entradas/salidas sin cambios)
- Sin movimientos arquitectónicos
- Métodos extraídos y nombrados como pasos significativos
- Expresiones repetidas extraídas donde mejora la claridad
- Variables renombradas; terminología consistente
- Código muerto e imports sin usar eliminados
Reflexión final
La refactorización Tipo 0 es la promesa más simple que puede hacer un desarrollador:
“Dejo este código más fácil de trabajar de como lo encontré, sin cambiar lo que hace.”
A veces es un “estaría bien tenerlo”.
Y a veces es la única forma en que un humano puede moverse rápido con seguridad dentro de un desorden de alta complejidad, especialmente durante un hotfix.
Comentarios