El código de refactorización es el proceso de reelaborar el código fuente de un programa de computadora , pero sin agregar funciones ni corregir errores, para mejorar la legibilidad y, en consecuencia, el mantenimiento, o hacerlo más genérico (para, por ejemplo, facilitar la cambio de precisión simple a múltiple); también hablamos de "reorganización". Esta técnica utiliza algunos métodos específicos para la optimización de código , con diferentes propósitos.
El término remanufactura se origina en Quebec . El equivalente en inglés es la refactorización de código , a veces traducida por refactorización , un término que, según la Office québécois de la langue française ( OQLF ), debe evitarse.
Durante la vida de un software, a menudo le agregamos funciones y, en cualquier caso, corregimos sus errores . Estas sucesivas modificaciones, por lo general, no mejoran la legibilidad del software, por lo que no facilitan su posterior mantenimiento.
El código fuente de un programa tiene todo el interés en permanecer, a pesar de sus modificaciones, lo más claro posible.
Las técnicas ágiles de programación , donde la evolución y la provisión se realizan de forma casi continua, hacen que este requisito sea aún más fundamental.
Para mantener siempre un código lo más simple posible, nosotros:
Durante la misma sesión de reelaboración, consideraremos estos diferentes niveles:
Este nivel mejora la presentación del código fuente sin modificar el código ejecutado: comentarios (borrado de comentarios superfluos, adición de comentarios sobre secciones complejas, etc.) y maquetación (sangría del código homogéneo, saltos de línea, etc.). Software como Eclipse o incluso el histórico cb ( embellecedor de C ) de Linux pueden facilitar esta operación cosmética, incluso cuidarla. Eclipse incluso ofrece varias variaciones.
Este tipo de modificación tiene como objetivo mantener los métodos lo más simples posible, por ejemplo, dividiendo un método o un algoritmo en varias partes o confiando parte del procesamiento a un objeto anexo.
Dado que este tipo de modificación introduce errores con frecuencia , necesariamente va acompañado de una batería de pruebas unitarias ejecutadas después de cada modificación propuesta para garantizar la no regresión .
Consiste en mover un procedimiento a otro procedimiento o al cuerpo principal de la clase. También puede inducir un desplazamiento de procedimiento en una clase principal ( pull-up ) o en una clase secundaria ( push-down ). (para completar).
Este cambio más radical cambia la jerarquía de clases que componen la aplicación. Las pruebas de progresividad y no regresión son más esenciales que nunca. El uso de un explorador de clases facilita el proceso.
El código muerto es el código que vemos que es inútil porque no es llamado por otra parte del programa. Sin duda útil en una etapa anterior de desarrollo o depuración , ya no tiene finalidad, hace más compleja la lectura del código fuente y distrae a los responsables del mantenimiento .
Para detectar el código muerto, se pueden utilizar las siguientes técnicas:
Otra forma de código muerto: el código comentado ( comentado ). A menudo sucede que después de las modificaciones, se dejan secciones enteras del código antiguo para poder volver fácilmente a la versión anterior. Este tipo de código también debe eliminarse al final de la sesión de desarrollo.
En cualquier caso, nunca se recomienda conservar un código que pueda usarse algún día . Siempre es mejor eliminarlo de la versión de trabajo y usar una herramienta de control de versiones para verificar este tipo de código.
Las afirmaciones definen un conjunto de reglas que debe seguir una aplicación en la programación de contratos . Son muy interesantes, por un lado, porque permiten simplificar la depuración detectando errores lo antes posible, pero también porque se colocan dentro del código que controlan y, por lo tanto, pueden ayudar a comprender el problema.
A medida que se desarrolla el software, el papel de las clases y los métodos se vuelve menos claro. Por lo tanto, a menudo es útil modificar los nombres de clases o métodos para indicar claramente este rol.
No hay consenso sobre el tema de los comentarios sobre la documentación del software . Sin embargo, es importante sincronizar siempre los comentarios, el código y la documentación externa (ver POD ).