La transformación  del software manteniendo su comportamiento y modificando su estructura interna para mejorarlo parte del proceso del desarrollo del software, los desarrolladores alterna la inserción de nuevas funcionalidad y casos de prueba con la refactorización del código para mejorar su consistencia interna y su claridad, los test aseguran que la refactorización no cambia el comportamiento del código,un proyecto de grandes dimensiones es frecuente encontrarse con la necesidad de modificar código creado anteriormente o ponerse a trabajar con un proyecto de otra persona para lo cual antes se deberá estudiar y comprender a pesar de los comentarios o la documentación

RAZONES

1-Calidad:Un código de calidad es un código sencillo y bien estructurado que cualquiera pueda leer y entender sin necesidad de haber estado integrado en el equipo de desarrollo del software

2-Eficiencia: mantener un buen diseño y un código estructurado es sin duda la forma mas eficiente evitar duplicación de código y en simplificar el diseño

3- Diseño evolutivo en lugar de un gran diseño inicial :cuando los requisitos van cambiando según van avanzando el proyecto el diseño inicial quedara anticuado por lo que refactorizar nos permitirá evolucionar el diseño según incluyamos nuevas funcionalidades.

4- Evitar la reescritura de código- en la mayoría de los casos refactorizar es mejor que reescribir debemos tener en cuenta que no es fácil enfrentarse a un código que no conocemos pero eso no es escusa suficiente  para no empezar desde cero refactorizando.

Buenas prácticas en el proceso de refactorización

•No añadir funcionalidad mientras se refactoriza: que el programa deberá comportarse de la misma forma antes y después de la refactorización.

•Un uso riguroso de las pruebas: no se debería comenzar ningún proceso de refactorización si no se dispone de un buen conjunto de pruebas, las pruebas serán necesarias para comprobar que una vez refactorizando el código el software mantiene su funcionalidad.

•Usar herramientas especializadas: las refactorizaciones en muchas ocasiones obligan a pequeñas modificaciones muy simples pero en muchas partes de nuestro código con la utilización de herramientas especializadas esta refactorizaciones se realizaran automáticamente y sin riesgo.

•Dar formación sobre patrones de refactorización y de diseño: una buena base teórica sobre las refactorizaciones más comunes permite al programador detectar los bad smells de los que no es consciente

•Refactorizar los principales fallos de diseño: es aconsejable comenzar realizando refactorizaciones concretas que corrigen los principales fallos de diseño que comenzar por refactorizaciones más complejas.

•Comenzar a refactorizar el código tras añadir cada nueva funcionalidad en grupo: una vez corregidos los errores del código existente la mejor manera de aplicar refactorización suele ser al añadir una nueva funcionalidad de manera que se desarrolle de la forma más eficiente.

•Implantar la refactorización continua al completo: cada programador incorpore la refactorización como una tarea más dentro del proceso de desarrollo de software.

BADSMELLS

•Código duplicado: o copiar código no es una buena práctica problema de duplicación de código es cuando tenemos la misma expresión expresiones en dos o más métodos de la misma clase hacer es extraer dicho código a un método e invocar al mismo en ambos lugares. Otro problema común de la duplicación es cuando tenemos la misma expresión en dos subclases hermanas en este caso podremos eliminar esta duplicación mediante extraer métodos de ambas clases y pasarlo a la clase padre

•Métodos excesivamente largos: los programas que tienen una vida más larga y mejor son aquellos que están formados por métodos cortos ya que estos son más reutilizables y aportan mayor semántica.

•Clases largas o grandes:clases demasiados grandes con demasiados métodos públicos o clase que hace demasiadas cosas por lo que no será fácil su modificación.

•Lista de parámetros larga: los métodos con demasiados parámetros son más difíciles de comprender y cambian con frecuencia.

•Tipos pequeños u obsesión primitiva: uso excesivo de tipos primitivos.

•Campos temporales o atributos temporales: atributos de clases que se usan para casos especiales en ciertas circunstancias 

•Comentarios no es autoexplicativo

•Estructuras de agrupación condicional: tener un switch con muchas clausulas case o muchos if anidados no es una buena práctica de programación 

•Ganchos especulativos o generalidad especulativa: consiste en un exceso de previsión a que en ocasiones los desarrolladores dejan todo tipo de ganchos para desarrollos futuros y estos ganchos pueden complicar la compresión del código

•Legado rechazado: clases que usan muy pocas cosas de las que sus padres les da.

•Intimidad inadecuada: clases que tratan con la parte privada de otras clases para solucionarlo se debe restringir el acceso al conocimiento interno de una clase

•Clases perezosas: si una clase no se usa o se usa muy poca y no tiene previsto usos futuros debemos considerar en eliminarla

•Envidia de datos o funcionalidades: se da cuando un método parece más interesado en datos guardados en otra clase que en los datos guardados en objetos de la propia clase.

•Grupos o pandillas de datos: si hay datos que siempre aparecen juntos debe considerarse la opción de agruparlos en una clase, con esto obtendremos como beneficios la reducción de la lista de parámetros y de las llamadas a los métodos

DOCUMENTACION

Documentar el código de un programa es añadir información como para explicar lo que hace punto por punto las personas entiendan que es lo que están haciendo y porque. Documentar un programa no es solo un acto del buen hacer del programador es una necesidad que solo se aprecia cuando hay errores que reparar o hay que extender el programa con nuevas capacidades para adaptarlo a un nuevo escenario.Por lo tanto la documentación de un programa empieza a la vez que la construcción del mismo y finaliza justo antes de la entrega del programa al cliente. La documentación es el conjunto de manuales impresos o en formato digital y cualquier otra información descriptiva que explique una aplicación o un programa.

•Una guía técnica: se refleja el diseño del proyecto, la codificación de la aplicación y las pruebas realizadas para su correcto funcionamiento. Generalmente este documento está diseñado para personas con conocimientos de informática generalmente programadores. El principal objetivo de esta guía es facilitar el desarrollo corrección y futuro mantenimiento de la aplicación de una forma fácil y rápida con esta documentación cualquier técnico que conozca el lenguaje con el que la aplicación ha sido creada debería poder conocerla casi tan bien como la creo, esta guía técnica está compuesta de 3 apartados claramente diferenciados:

•Cuaderno de carga: es donde queda reflejada la solución o el diseño de la aplicación este apartado está destinado a los programadores y debe estar realizado de tal forma que permita la división del trabajo.

•Programa fuente: Es donde se incluye la codificación realizada por los programadores, este documento puede tener a su vez otra documentación adjunta para su mejor compresión y puede ser de gran ayuda para el mantenimiento o desarrollo mejorado de la aplicación.

•Pruebas: documento donde se especifican el tipo de pruebas realizadas a lo largo de todo el proyecto y los resultados obtenidos.

•Una guía de uso e instalación: la guía de uso es lo que comúnmente llamamos manual de usuario y contiene la información necesaria para que los usuarios finales puedan utilizar correctamente la aplicación este documento se hace a partir de la guía técnica pero se suprimen todos los tecnicismos y se presenta de forma que sea entendible para el usuario que no sea experto en informática, en caso de que en el manual de usuario incluya algún tecnicismo debe ir acompañado de un glosario para entender la expresión