Leer antes de cambiar
Reconoce la deuda técnica
Distingue una decisión temporal de un problema olvidado y refactoriza sin cambiar el resultado.
Qué aprenderás
- Relacionar una decisión de hoy con su costo de mantenimiento.
- Registrar una deuda con una acción concreta.
- Separar refactorización de cambio de comportamiento.
Índice de esta lección
Paso 1
Encuentra el costo, no solo el defecto
Imagina una regla de descuentos repetida en tres pantallas. Hoy funciona, pero cada cambio exige encontrar y corregir las tres copias. Ese esfuerzo futuro es el interés de la deuda.
No todo código que te disgusta es una deuda prioritaria. Describe qué cambio se vuelve más lento, qué error es más probable y a quién afecta.
Problema: la regla de descuento está duplicada.Costo: cada cambio requiere editar tres pantallas.Riesgo: una pantalla puede calcular otro total.Siguiente paso: cubrir la regla con pruebas y extraerla.Qué deberías observar
La nota explica una consecuencia observable y propone una acción.
Paso 2
Distingue intención y criterio
Los apuntes separan cuatro situaciones: una decisión consciente puede ser prudente o imprudente; también podemos descubrir una deuda que no habíamos visto.
No uses el cuadrante para etiquetar a una persona. Úsalo para entender la decisión y acordar qué hacer con lo aprendido.
Prudente + deliberadaAceptamos un atajo, medimos su costo y fijamos una revisión. Imprudente + deliberadaDuplicamos la regla sin evaluar qué se romperá después. Prudente + inadvertidaAprendimos más del negocio y ahora vemos una mejor separación. Imprudente + inadvertidaNo reconocimos un acoplamiento y seguimos ampliándolo.Qué deberías observar
Puedes describir el contexto de una deuda sin asumir que toda decisión temporal fue un error.
Paso 3
Haz explícita la intención
Lee el ejemplo Antes. Para saber qué recibe la función hay que descifrar p, q y d.
En Después, los nombres explican el precio unitario, la cantidad y que el descuento es una proporción. La fórmula permanece igual: cambiarla sería otro trabajo.
export function calculateOrderTotal( unitPrice: number, quantity: number, discountRate: number,): number { const subtotal = unitPrice * quantity; return subtotal * (1 - discountRate);}Qué deberías observar
Para precio 50, cantidad 2 y descuento 0.1, ambas funciones devuelven 90.
Paso 4
Verifica también los extremos
No te quedes con un único pedido. Comprueba cantidad cero, descuento cero, descuento completo y precios fraccionarios.
Las pruebas no demuestran todo lo posible, pero documentan los casos que decidiste conservar. No añadas una regla nueva escondida en un cambio de nombres.
assert.equal(calculateOrderTotal(50, 2, 0.1), 90);assert.equal(calculateOrderTotal(50, 0, 0.1), 0);assert.equal(calculateOrderTotal(50, 2, 0), 100);assert.equal(calculateOrderTotal(50, 2, 1), 0);assert.equal(calculateOrderTotal(2.5, 3, 0.2), 6);Qué deberías observar
npm test pasa antes y después. El contrato del cálculo sigue siendo el mismo.
Ahora te toca
Prueba la idea por tu cuenta
Escribe una nota de deuda para una función de tu proyecto. Incluye el costo observable, una acción pequeña y cuándo revisarías la decisión.
Necesito una pista
“El código está feo” no describe un costo. “Cambiar una tarifa requiere editar cuatro archivos” sí lo describe.
Comparar con una solución
Ejemplo: la tarifa se repite en cuatro archivos; una actualización puede dejarlos inconsistentes. Primero cubriré los valores actuales con pruebas y luego centralizaré el cálculo. Lo revisaré antes del próximo cambio de tarifa.
Antes de seguir
Comprueba lo que aprendiste
No es una nota. Es una pausa para comprobar que la idea quedó clara.
¿Terminaste la práctica?
Haz el ejercicio y comprueba tus respuestas antes de marcar la lección como completada.