Refactorizar kata siguiendo clean code

[amlndz]

🎯 Objetivo de la issue

Refactorizar el código de Gilded Rose para mejorar su legibilidad, mantenibilidad y extensibilidad, sin cambiar el comportamiento observable del sistema.

El refactor debe estar guiado por tests, asegurando que las reglas de negocio actuales estén correctamente cubiertas y que cualquier cambio estructural mantenga el comportamiento intacto.

📌 Contexto

El código actual de Gilded Rose:

• Contiene lógica compleja y condicionales anidados.
• Es difícil de extender para nuevos tipos de items.
• No expresa claramente las reglas de negocio.

Antes de refactorizar, es imprescindible proteger el comportamiento actual con tests significativos, evitando tests redundantes o de bajo valor.

🧪 Paso 1: Entender las reglas de negocio

Antes de escribir tests o refactorizar:

• Leer cuidadosamente la descripción del kata de Gilded Rose.
• Identificar y listar explícitamente las reglas de negocio, por ejemplo:
  • Items normales degradan su quality en 1 por día.
  • Una vez pasada la fecha de venta (sellIn < 0), la degradación se duplica.
  • Aged Brie incrementa su quality.
  • Backstage passes incrementan su quality según el sellIn y caen a 0 después del concierto.
  • Sulfuras no cambia ni sellIn ni quality.
  • quality nunca es negativa ni mayor a 50 (excepto Sulfuras).

Estas reglas deben reflejarse en los tests.

🧪 Paso 2: Crear tests antes de refactorizar

Principios para los tests

❌ No crear tests innecesarios o duplicados.

✅ Crear tests que:

• Cubran todas las reglas de negocio.
• Cubran casos límite (bordes).
• Sirvan como red de seguridad para el refactor.

Qué tipos de tests escribir

• Tests por tipo de item (no por método).
• Tests enfocados en comportamiento, no en implementación.
• Tests claros y expresivos (el nombre del test debe explicar la regla).

Ejemplos de casos a cubrir

Item normal:

• Degrada quality en 1 antes del sell date.
• Degrada quality en 2 después del sell date.
• Nunca baja de 0.

Aged Brie:

• Incrementa quality cada día.
• Nunca supera 50.
• Backstage passes:
• Incrementa en +1 cuando sellIn > 10.
• Incrementa en +2 cuando sellIn <= 10.
• Incrementa en +3 cuando sellIn <= 5.
• Quality pasa a 0 cuando sellIn < 0.

Sulfuras:

• No cambia ni sellIn ni quality.

📌 Importante:
Antes de continuar, todos los tests deben pasar en el código actual.

✅ Paso 3: Verificar cobertura y confianza

Ejecutar los tests y asegurarse de que:

• Todas las reglas de negocio están cubiertas.
• Los casos límite están testeados.
• Revisar cobertura de código:
• La cobertura es un indicador, no el objetivo.
• Priorizar cobertura de reglas, no líneas.
• Confirmar que los tests fallarían si se rompe alguna regla de negocio.

🔧 Paso 4: Refactorizar paso a paso

Refactorizar en pequeños pasos, ejecutando los tests constantemente.

Posibles pasos (no obligatorios, pero recomendados):

• Buscar un mejor naming para las variables
• Simplificar condicionales complejos y usar clausulas de guarda.
• Extraer métodos con nombres expresivos.
• Eliminar código duplicado.
• Eliminar magic numbers/strings
• Aplicar polimorfismo o estrategia por tipo de item.
• Introducir clases específicas por item si aporta claridad.

Mantener la lógica de negocio explícita y legible.

⚠️ En ningún momento deben romperse los tests existentes y lo suyo sería que por cada cambio que vayas haciendo corras los test para asegurar que no se ha roto nada

🔁 Paso 5: Validación final

Ejecutar toda la suite de tests.

Verificar que:

• No se han añadido tests redundantes.
• El código es más fácil de entender que antes.
• Añadir un nuevo tipo de item sería sencillo.
• Revisar que no haya cambios en el comportamiento funcional.

📦 Resultado esperado

Código refactorizado, más limpio y mantenible con tests que documentan las reglas de negocio.
Comportamiento intacto.
Base preparada para futuras extensiones.