Refactorización de código TypeScript: cuándo y cómo convertir el caos en orden

Introducción: cuando el código empieza a «oler mal»

Todo desarrollador conoce esa sensación. Abres un archivo que escribiste hace tres meses y tu cara se alarga. En algún lugar profundo de tu alma escuchas un susurro: «Esto no lo escribí yo, fue algún novato». Pero el espejo retrovisor es implacable: fuiste tú. El código funciona, las pruebas pasan, pero cada vez que agregas una nueva funcionalidad, tardas más y más tiempo. ¿Te suena familiar?

Este es el momento de pensar en la refactorización de código TypeScript. No en reescribir todo desde cero (ese es el camino al infierno), sino en mejoras quirúrgicamente precisas que hacen que el código sea más limpio, comprensible y seguro. En este artículo, analizaremos cuándo vale la pena comenzar la refactorización, cómo hacerlo sin dolor y por qué TypeScript te da superpoderes para este proceso.

¿Cuándo se debe realizar la refactorización de código TypeScript?

Existe el mito de que la refactorización es una tarea separada en el sprint. En la práctica, la mejor refactorización es un proceso continuo. Pero hay señales claras que gritan: «¡Alto! ¡Aquí se necesita orden!».

La regla de tres (y dos más)

Si has copiado el mismo fragmento de código tres veces, extráelo a una función o clase. Si ves que un colega copió tu código, esa es la cuarta vez. TypeScript con su tipado estricto hace que esta regla sea especialmente importante: la duplicación de tipos conduce a la desincronización de datos.

Síntomas de código «sucio» en TypeScript

• Caos de any: Si en tu proyecto any aparece más seguido que string — es una bandera roja. TypeScript pierde su sentido.
• Funciones monstruo: Una función de más de 200 líneas que lo hace todo: valida, parsea, envía solicitudes y dibuja la interfaz.
• Números y cadenas «mágicas»: if (status === 3) — ¿qué es 3? Nadie lo sabe, excepto el autor, que ya renunció.
• Violación del principio DRY: Interfaces idénticas dispersas en 10 archivos.
• Pruebas más aterradoras que el código: Si para probar una función necesitas levantar un servidor, una base de datos y ejecutar Docker — te desviaste del camino.

Recuerda la regla principal: la refactorización de código TypeScript debe hacerse cuando agregar una nueva funcionalidad lleva más tiempo que escribirla desde cero. Ese es el momento de la verdad.

Principios básicos: cómo no romper producción

Antes de comenzar con la refactorización, recuerda los tres pilares sobre los que se basa una refactorización segura:

1. Las pruebas son tu seguro. Sin cobertura de pruebas, la refactorización es una ruleta rusa. Escribe al menos pruebas unitarias básicas antes de empezar.
2. Pasos pequeños. No intentes refactorizar todo el proyecto en una noche. Un módulo — un commit.
3. El compilador de TypeScript es tu amigo. Usa configuraciones estrictas en tsconfig.json: strict: true — es tu detector de mentiras.

Técnicas prácticas de refactorización con ejemplos en TypeScript

Pasemos a lo más interesante: el código. Veremos tres situaciones reales y mostraremos cómo mejorarlas.

1. Deshacerse de any: el poder de los genéricos

Ejemplo malo. La función acepta cualquier cosa y devuelve cualquier cosa. Esto no es TypeScript, es JavaScript con máscara.

// MALO: any destruye el tipadofunction getFirstElement(arr: any[]): any {  if (arr.length === 0) {    throw new Error('Array is empty');  }  return arr[0];}

const num = getFirstElement([1, 2, 3]); // num: anyconsole.log(num.toUpperCase()); // Error en tiempo de ejecución, pero el compilador calla

Ejemplo bueno. Usamos genéricos. El código se vuelve más seguro y el IDE sugiere tipos.

// BUENO: los genéricos salvanfunction getFirstElement<T>(arr: T[]): T {  if (arr.length === 0) {    throw new Error('Array is em