Refactorización - Revision history

Mberne: /* Referencias */

2026-05-19T14:54:17Z

Referencias

← Older revision		Revision as of 16:54, 19 May 2026
Line 34:		Line 34:
	</div>		</div>
	== Referencias ==		== Referencias ==
	Beck, Kent. (2000). ''Extreme Programming Explained: Embrace Change''. Addison-Wesley Professional.		* Beck, Kent. (2000). ''Extreme Programming Explained: Embrace Change''. Addison-Wesley Professional.
			* Fowler, Martin. (1999). ''Refactoring: Improving the Design of Existing Code''. Addison-Wesley Professional.
	Fowler, Martin. (1999). ''Refactoring: Improving the Design of Existing Code''. Addison-Wesley Professional.

	== Véase también ==		== Véase también ==

Mberne at 10:50, 19 May 2026

2026-05-19T10:50:29Z

← Older revision		Revision as of 12:50, 19 May 2026
Line 53:		Line 53:
	</div>		</div>
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Practicas_tecnicas~~]]		[[Category:Prácticas técnicas]]
	[[Category:~~Practicas_agiles~~]]		[[Category:Prácticas ágiles]]

Mberne: /* Cuándo refactorizar */

2026-05-19T10:27:40Z

Cuándo refactorizar

← Older revision		Revision as of 12:27, 19 May 2026
Line 5:		Line 5:
	== Cuándo refactorizar ==		== Cuándo refactorizar ==
	La refactorización no es una actividad separada del desarrollo: es algo que los desarrolladores hacen de forma continua. Fowler propone la "regla del campamento": deja el código un poco mejor de como lo encontraste.		La refactorización no es una actividad separada del desarrollo: es algo que los desarrolladores hacen de forma continua. Fowler propone la "regla del campamento": deja el código un poco mejor de como lo encontraste.
	~~Situaciones que invitan a refactorizar:~~

	Al añadir una nueva funcionalidad que requeriría código duplicado o lógica enredada.		'''Situaciones que invitan a refactorizar:'''
	Al corregir un error cuya causa raíz es una mala estructura del código.		* Al añadir una nueva funcionalidad que requeriría código duplicado o lógica enredada.
	Después de una revisión de código que identifica áreas de mejora.		* Al corregir un error cuya causa raíz es una mala estructura del código.
	Al revisar código heredado que hay que extender.		* Después de una revisión de código que identifica áreas de mejora.
			* Al revisar código heredado que hay que extender.

	== Relación con TDD ==		== Relación con TDD ==

Mberne: /* Referencias */

2026-05-19T10:27:16Z

Referencias

← Older revision		Revision as of 12:27, 19 May 2026
Line 34:		Line 34:
	</div>		</div>
	== Referencias ==		== Referencias ==
			Beck, Kent. (2000). ''Extreme Programming Explained: Embrace Change''. Addison-Wesley Professional.

	Fowler, Martin. (1999). ''Refactoring: Improving the Design of Existing Code''. Addison-Wesley Professional.		Fowler, Martin. (1999). ''Refactoring: Improving the Design of Existing Code''. Addison-Wesley Professional.
	~~Beck, Kent. (2000). ''Extreme Programming Explained: Embrace Change''. Addison-Wesley Professional.~~

	== Véase también ==		== Véase también ==

Mberne: /* Refactorización del código generado por IA */

2026-05-19T10:26:38Z

Refactorización del código generado por IA

← Older revision		Revision as of 12:26, 19 May 2026
Line 21:		Line 21:
	== Refactorización del código generado por IA ==		== Refactorización del código generado por IA ==
	La adopción de herramientas de IA generativa ha hecho la refactorización más necesaria, no menos:		La adopción de herramientas de IA generativa ha hecho la refactorización más necesaria, no menos:
			* El código generado por IA funciona, pero rara vez está bien estructurado. Tiende a ser poco modular, con duplicaciones y con nombres de variables genéricos.
	El código generado por IA funciona, pero rara vez está bien estructurado. Tiende a ser poco modular, con duplicaciones y con nombres de variables genéricos.		* El vibe coding —escribir código conversacionalmente con un asistente de IA hasta que "funciona"— genera deuda técnica a una velocidad sin precedentes. La refactorización es la práctica que permite estabilizar ese código antes de que pase a producción.
	El vibe coding —escribir código conversacionalmente con un asistente de IA hasta que "funciona"— genera deuda técnica a una velocidad sin precedentes. La refactorización es la práctica que permite estabilizar ese código antes de que pase a producción.		* En el modelo de doble carril (carril rápido para prototipos, carril robusto para producción), la refactorización es el proceso central de transición: lo que en el carril rápido era código experimental se refactoriza hasta cumplir los estándares del carril robusto.
	En el modelo de doble carril (carril rápido para prototipos, carril robusto para producción), la refactorización es el proceso central de transición: lo que en el carril rápido era código experimental se refactoriza hasta cumplir los estándares del carril robusto.

	<div class="bok-aviso">		<div class="bok-aviso">
	La IA puede sugerir refactorizaciones, pero no puede tomar las decisiones de diseño que las justifican. Una refactorización bien hecha requiere entender el contexto del sistema, los requisitos futuros previsibles y los compromisos entre legibilidad, rendimiento y mantenibilidad. Delegar estas decisiones completamente a la IA produce código que parece limpio superficialmente pero que no resuelve los problemas estructurales de fondo.		La IA puede sugerir refactorizaciones, pero no puede tomar las decisiones de diseño que las justifican. Una refactorización bien hecha requiere entender el contexto del sistema, los requisitos futuros previsibles y los compromisos entre legibilidad, rendimiento y mantenibilidad. Delegar estas decisiones completamente a la IA produce código que parece limpio superficialmente pero que no resuelve los problemas estructurales de fondo.
	</div>		</div>

	== Error frecuente ==		== Error frecuente ==
	<div class="bok-aviso">		<div class="bok-aviso">

Mberne: /* Relación con TDD */

2026-05-19T10:26:06Z

Relación con TDD

← Older revision		Revision as of 12:26, 19 May 2026
Line 14:		Line 14:
	== Relación con TDD ==		== Relación con TDD ==
	La refactorización forma el tercer paso del ciclo de [[TDD\|Test-Driven Development]]:		La refactorización forma el tercer paso del ciclo de [[TDD\|Test-Driven Development]]:
	Escribir una prueba que falla (rojo).		* Escribir una prueba que falla (rojo).
	Escribir el mínimo código que la hace pasar (verde).		* Escribir el mínimo código que la hace pasar (verde).
	'''Refactorizar''' el código manteniendo las pruebas en verde.		* '''Refactorizar''' el código manteniendo las pruebas en verde.
	Las pruebas unitarias son el mecanismo de seguridad que permite refactorizar con confianza: si todas siguen pasando después de reestructurar el código, el comportamiento externo no ha cambiado.		Las pruebas unitarias son el mecanismo de seguridad que permite refactorizar con confianza: si todas siguen pasando después de reestructurar el código, el comportamiento externo no ha cambiado.

	== Refactorización del código generado por IA ==		== Refactorización del código generado por IA ==
	La adopción de herramientas de IA generativa ha hecho la refactorización más necesaria, no menos:		La adopción de herramientas de IA generativa ha hecho la refactorización más necesaria, no menos:

Mberne at 10:25, 19 May 2026

2026-05-19T10:25:46Z

← Older revision		Revision as of 12:25, 19 May 2026
Line 1:		Line 1:
	{{Meta-bok\|min=4}}		{{Meta-bok\|min=4}}
	~~<div class="bok-def">~~
	La '''refactorización''' es la reestructuración del código fuente que mejora su estructura interna sin modificar el comportamiento externo del programa. Su objetivo es mejorar la consistencia, la claridad y la mantenibilidad del código: eliminar duplicaciones, simplificar lógica compleja, mejorar nombres de variables y funciones, y aplicar buenas prácticas de diseño.		La '''refactorización''' es la reestructuración del código fuente que mejora su estructura interna sin modificar el comportamiento externo del programa. Su objetivo es mejorar la consistencia, la claridad y la mantenibilidad del código: eliminar duplicaciones, simplificar lógica compleja, mejorar nombres de variables y funciones, y aplicar buenas prácticas de diseño.
	~~</div>~~
	Es una práctica especialmente recomendada en programación ágil como garantía de calidad y para evitar que el cambio continuo genere [[Deuda técnica\|deuda técnica]]. Martin Fowler la describió y sistematizó en su libro ''Refactoring: Improving the Design of Existing Code'' (1999), que sigue siendo la referencia fundamental en la materia.		Es una práctica especialmente recomendada en programación ágil como garantía de calidad y para evitar que el cambio continuo genere [[Deuda técnica\|deuda técnica]]. Martin Fowler la describió y sistematizó en su libro ''Refactoring: Improving the Design of Existing Code'' (1999), que sigue siendo la referencia fundamental en la materia.
	== Cuándo refactorizar ==		== Cuándo refactorizar ==

Mberne at 10:25, 19 May 2026

2026-05-19T10:25:39Z

@@ Line 1: / Line 1: @@
-La '''refactorización''' es la re-estructuración del código fuente, alterando su estructura interna, sin modificar el comportamiento del programa, con la finalidad de "limpiar el código": mejorar la consistencia interna, claridad, comprensión en general su calidad.
+{{Meta-bok|min=4}}
-Se recomienda realizar la refactorización, seguida de pruebas unitarias para comprobar que no ha cambiado el comportamiento del código.
+Al añadir una nueva funcionalidad que requeriría código duplicado o lógica enredada.
-Es una práctica especialmente recomendada en programación ágil, como garantía de calidad y para evitar que el cambio continuo genere "deuda técnica".
+== Relación con TDD ==
-==Véase también==
+El código generado por IA funciona, pero rara vez está bien estructurado. Tiende a ser poco modular, con duplicaciones y con nombres de variables genéricos.
-*[[Deuda técnica]].
+El vibe coding —escribir código conversacionalmente con un asistente de IA hasta que "funciona"— genera deuda técnica a una velocidad sin precedentes. La refactorización es la práctica que permite estabilizar ese código antes de que pase a producción.
 [[Category:Glosario de términos]]
-[[Category:Prácticas_técnicas]]
+[[Category:Practicas_tecnicas]]
-[[Category:Prácticas ágiles]]
+[[Category:Practicas_agiles]]

Mberne at 14:50, 11 May 2026

2026-05-11T14:50:10Z

← Older revision		Revision as of 16:50, 11 May 2026
Line 9:		Line 9:
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Prácticas_técnicas]]		[[Category:Prácticas_técnicas]]
			[[Category:Prácticas ágiles]]

Mberne at 13:55, 11 May 2026

2026-05-11T13:55:23Z

← Older revision		Revision as of 15:55, 11 May 2026
Line 8:		Line 8:
	*[[Deuda técnica]].		*[[Deuda técnica]].
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:~~Prácticas ágiles~~]]		[[Category:Prácticas_técnicas]]