Refactorización de código

En programación informática y diseño de software , la refactorización de código es el proceso de reestructuración del código fuente existente (cambiando la factorización ) sin cambiar su comportamiento externo. La refactorización tiene como objetivo mejorar el diseño, la estructura y/o la implementación del software (sus atributos no funcionales ), al tiempo que se preserva su funcionalidad . Las posibles ventajas de la refactorización pueden incluir una mejor legibilidad del código y una menor complejidad ; estas pueden mejorar la capacidad de mantenimiento del código fuente y crear una arquitectura interna o un modelo de objetos más simple, más limpio o más expresivo para mejorar la extensibilidad . Otro objetivo potencial de la refactorización es mejorar el rendimiento; los ingenieros de software se enfrentan al desafío constante de escribir programas que funcionen más rápido o utilicen menos memoria.

Por lo general, la refactorización aplica una serie de microrrefactorizaciones básicas estandarizadas , cada una de las cuales es (normalmente) un cambio minúsculo en el código fuente de un programa informático que preserva el comportamiento del software o, al menos, no modifica su conformidad con los requisitos funcionales. Muchos entornos de desarrollo proporcionan soporte automatizado para realizar los aspectos mecánicos de estas refactorizaciones básicas. Si se hace bien, la refactorización de código puede ayudar a los desarrolladores de software a descubrir y corregir errores o vulnerabilidades ocultos o latentes en el sistema simplificando la lógica subyacente y eliminando niveles innecesarios de complejidad. Si se hace mal, puede no cumplir con el requisito de que no se modifique la funcionalidad externa y, por lo tanto, puede introducir nuevos errores.

Al mejorar continuamente el diseño del código, hacemos que sea cada vez más fácil trabajar con él. Esto contrasta claramente con lo que ocurre normalmente: poca refactorización y mucha atención para agregar nuevas características de manera oportuna. Si adquiere el hábito higiénico de refactorizar continuamente, descubrirá que es más fácil ampliar y mantener el código.

—  Joshua Kerievsky, Refactorización a patrones ^[1]

La refactorización suele estar motivada por la detección de un olor extraño en el código . ^[2] Por ejemplo, el método en cuestión puede ser muy largo o puede ser un duplicado casi idéntico de otro método cercano. Una vez identificados, estos problemas se pueden solucionar refactorizando el código fuente o transformándolo en una nueva forma que se comporte igual que antes pero que ya no "huela".

En el caso de una rutina larga, se pueden extraer una o más subrutinas más pequeñas; o en el caso de rutinas duplicadas, se puede eliminar la duplicación y reemplazarla con una función compartida. Si no se realiza la refactorización, se puede acumular deuda técnica ; por otro lado, la refactorización es uno de los principales medios para saldar la deuda técnica. ^[3]

Hay dos categorías generales de beneficios de la actividad de refactorización.

1. Mantenibilidad . Es más fácil corregir errores porque el código fuente es fácil de leer y la intención de su autor es fácil de entender. ^[4] Esto se puede lograr reduciendo grandes rutinas monolíticas a un conjunto de métodos concisos, bien nombrados y de propósito único. Se puede lograr moviendo un método a una clase más apropiada o eliminando comentarios engañosos.
2. Extensibilidad . Es más fácil ampliar las capacidades de la aplicación si utiliza patrones de diseño reconocibles y proporciona cierta flexibilidad donde antes no existía. ^[1]

La ingeniería de rendimiento puede eliminar las ineficiencias de los programas, conocidas como "software bloat", que surgen de las estrategias tradicionales de desarrollo de software que apuntan a minimizar el tiempo de desarrollo de una aplicación en lugar del tiempo que lleva ejecutarla. La ingeniería de rendimiento también puede adaptar el software al hardware en el que se ejecuta, por ejemplo, para aprovechar los procesadores paralelos y las unidades vectoriales. ^[5]

Hay dos momentos posibles para la refactorización.

1. Refactorización preventiva: el desarrollador original del código hace que el código sea más robusto cuando aún está libre de olores para evitar la formación de olores en el futuro. ^[6]
2. Refactorización correctiva: un desarrollador posterior realiza una refactorización para corregir los errores de código a medida que ocurren. ^[6]

Un método que equilibra la refactorización preventiva y correctiva es la "responsabilidad compartida de la refactorización". Este enfoque divide la acción de refactorización en dos etapas y dos roles. El desarrollador original del código simplemente prepara el código para la refactorización y, cuando el código huele mal, un desarrollador posterior lleva a cabo la acción de refactorización real. ^[6]

La refactorización requiere extraer la estructura del sistema de software, los modelos de datos y las dependencias entre aplicaciones para recuperar el conocimiento de un sistema de software existente. ^[7] La ​​rotación de equipos implica la falta de conocimiento o la falta de conocimiento preciso sobre el estado actual de un sistema y sobre las decisiones de diseño tomadas por los desarrolladores que se van. Las actividades de refactorización de código posteriores pueden requerir un esfuerzo adicional para recuperar este conocimiento. ^[8] Las actividades de refactorización generan modificaciones arquitectónicas que deterioran la arquitectura estructural de un sistema de software. Tal deterioro afecta a las propiedades arquitectónicas, como la capacidad de mantenimiento y la comprensión, lo que puede llevar a un nuevo desarrollo completo de los sistemas de software. ^[9]

Las actividades de refactorización de código se protegen con inteligencia de software cuando se utilizan herramientas y técnicas que proporcionan datos sobre algoritmos y secuencias de ejecución de código. ^[10] Proporcionar un formato comprensible para el estado interno de la estructura del sistema de software, los modelos de datos y las dependencias entre componentes es un elemento fundamental para formar una comprensión de alto nivel y luego puntos de vista refinados de lo que se debe modificar y cómo. ^[11]

Se deben configurar pruebas unitarias automáticas antes de la refactorización para garantizar que las rutinas sigan comportándose como se espera. ^[12] Las pruebas unitarias pueden aportar estabilidad incluso a refactorizaciones grandes cuando se realizan con una única confirmación atómica . Una estrategia común para permitir refactorizaciones seguras y atómicas que abarquen varios proyectos es almacenar todos los proyectos en un único repositorio , conocido como monorepo . ^[13]

Una vez que se han realizado las pruebas unitarias, la refactorización es un ciclo iterativo que consiste en realizar una pequeña transformación del programa , probarla para garantizar su corrección y realizar otra pequeña transformación. Si en algún momento una prueba falla, el último cambio pequeño se deshace y se repite de una manera diferente. A través de muchos pasos pequeños, el programa pasa de donde estaba a donde se desea que esté. Para que este proceso tan iterativo sea práctico, las pruebas deben ejecutarse muy rápidamente, o el programador tendría que dedicar una gran parte de su tiempo a esperar a que finalicen las pruebas. Los defensores de la programación extrema y otros desarrollos de software ágiles describen esta actividad como una parte integral del ciclo de desarrollo de software .

A continuación se muestran algunos ejemplos de microrrefactorizaciones; algunas de ellas pueden aplicarse únicamente a determinados lenguajes o tipos de lenguaje. Se puede encontrar una lista más larga en el libro de refactorización de Martin Fowler ^{[2] [ página necesaria ]} y en el sitio web. ^[14] Muchos entornos de desarrollo proporcionan soporte automatizado para estas microrrefactorizaciones. Por ejemplo, un programador podría hacer clic en el nombre de una variable y luego seleccionar la refactorización "Encapsular campo" en un menú contextual . El IDE solicitaría entonces detalles adicionales, normalmente con valores predeterminados razonables y una vista previa de los cambios en el código. Después de la confirmación por parte del programador, llevaría a cabo los cambios necesarios en todo el código.

• Técnicas que permiten una mayor comprensión
  • Gráfico de dependencia del programa : representación explícita de dependencias de datos y control ^[15]
  • Gráfico de dependencia del sistema: representación de llamadas a procedimientos entre PDG ^[16]
  • Inteligencia de software : realiza ingeniería inversa del estado inicial para comprender las dependencias existentes dentro de la aplicación.
• Técnicas que permiten una mayor abstracción
  • Encapsular campo : obligar al código a acceder al campo con métodos getter y setter
  • Generalizar tipo : crear tipos más generales para permitir un mayor intercambio de código
  • Reemplazar el código de verificación de tipos con estado/estrategia ^[17]
  • Reemplazar condicional por polimorfismo ^[18]
• Técnicas para dividir el código en partes más lógicas
  • La componentización divide el código en unidades semánticas reutilizables que presentan interfaces claras, bien definidas y fáciles de usar.
  • Extraer clase mueve parte del código de una clase existente a una nueva clase.
  • Extraer método, para convertir parte de un método más grande en un nuevo método. Al dividir el código en partes más pequeñas, es más fácil de entender. Esto también se aplica a las funciones .
• Técnicas para mejorar los nombres y la ubicación del código
  • Mover método o mover campo: mover a una clase o archivo fuente más apropiado
  • Cambiar el nombre del método o cambiar el nombre del campo: cambiar el nombre por uno nuevo que revele mejor su propósito
  • Pull up – en programación orientada a objetos (OOP), moverse a una superclase
  • Empujar hacia abajo: en programación orientada a objetos, mover a una subclase ^[14]
• Detección automática de clones ^[19]

Aunque el término refactorización originalmente se refería exclusivamente a la refactorización de código de software, en los últimos años también se ha refactorizado código escrito en lenguajes de descripción de hardware . El término refactorización de hardware se utiliza como un término abreviado para la refactorización de código en lenguajes de descripción de hardware. Dado que la mayoría de los ingenieros de hardware no consideran que los lenguajes de descripción de hardware sean lenguajes de programación , ^[20] la refactorización de hardware debe considerarse un campo separado de la refactorización de código tradicional.

Zeng y Huss propusieron la refactorización automatizada de descripciones de hardware analógico (en VHDL-AMS ). ^[21] En su enfoque, la refactorización preserva el comportamiento simulado de un diseño de hardware. La medida no funcional que mejora es que el código refactorizado puede procesarse con herramientas de síntesis estándar, mientras que el código original no. La refactorización de lenguajes de descripción de hardware digital, aunque sea manual, también ha sido investigada por Mike Keating , miembro de Synopsys . ^{[22] [23]} Su objetivo es hacer que los sistemas complejos sean más fáciles de entender, lo que aumenta la productividad de los diseñadores.

El primer uso conocido del término "refactorización" en la literatura publicada fue en un artículo de septiembre de 1990 de William Opdyke y Ralph Johnson . ^[24] Aunque la refactorización de código se ha realizado de manera informal durante décadas, la disertación de doctorado de 1991 de William Griswold ^[25] es uno de los primeros trabajos académicos importantes sobre la refactorización de programas funcionales y procedimentales, seguida por la disertación de 1992 de William Opdyke ^[26] sobre la refactorización de programas orientados a objetos, ^[27] aunque toda la teoría y la maquinaria han estado disponibles desde hace mucho tiempo como sistemas de transformación de programas . Todos estos recursos proporcionan un catálogo de métodos comunes para la refactorización; un método de refactorización tiene una descripción de cómo aplicar el método e indicadores de cuándo debe (o no debe) aplicar el método.

El libro de Martin Fowler Refactoring: Improving the Design of Existing Code es la referencia canónica. ^{[ ¿según quién? ]}

Los términos "factorización" y "factorización externa" se han utilizado de esta manera en la comunidad Forth al menos desde principios de los años 1980. El capítulo seis del libro de Leo Brodie Thinking Forth (1984) ^[28] está dedicado a este tema.

En programación extrema, la técnica de refactorización del método Extract tiene esencialmente el mismo significado que la factorización en Forth: dividir una "palabra" (o función ) en funciones más pequeñas y más fáciles de mantener.

Las refactorizaciones también se pueden reconstruir ^[29] post hoc para producir descripciones concisas de cambios de software complejos registrados en repositorios de software como CVS o SVN.

Esta sección necesita citas adicionales para su verificación . Por favor, ayude a mejorar este artículo añadiendo citas de fuentes fiables en esta sección. El material sin fuentes puede ser cuestionado y eliminado. Buscar fuentes:  «Refactorización de código» – noticias  · periódicos  · libros  · académico  · JSTOR ( julio de 2018 ) ( Aprenda cómo y cuándo eliminar este mensaje )

Muchos editores de software e IDE cuentan con soporte para refactorización automatizada. A continuación, se incluye una lista de algunos de estos editores, o los denominados navegadores de refactorización .

• Kit de herramientas de reingeniería de software DMS (implementa refactorización a gran escala para C, C++, C#, COBOL, Java, PHP y otros lenguajes)
• Basado en Eclipse:
  • Eclipse (para Java y, en menor medida, C++, PHP, Ruby y JavaScript)
  • PyDev (para Python )
  • Photran (un complemento de Fortran para el IDE de Eclipse )
• Embarcadero Delphi
• Basado en IntelliJ:
  • Resharper (para C# )
  • AppCode (para Objective-C , C y C++)
  • IntelliJ IDEA (para Java )
  • PyCharm (para Python )
  • WebStorm (para JavaScript )
  • PhpStorm (para PHP )
  • Android Studio (para Java y C++)
• JDeveloper (para Java )
• NetBeans (para Java )
• Smalltalk : la mayoría de los dialectos incluyen potentes herramientas de refactorización. Muchos utilizan el navegador de refactorización original creado a principios de los años 90 por Ralph Johnson .
• Basado en Visual Studio:
  • Visual Studio (para .NET y C++)
  • Visual Assist (complemento para Visual Studio con soporte de refactorización para C# y C++)
• Wing IDE (para Python )
• Xcode (para C, Objective-C y Swift ) ^[30]
• Qt Creator (para C++, Objective-C y QML) ^[31]

• Patrón de mejora
• Revisión de código
• Refactorización de bases de datos
• Descomposición (informática)
• Programación modular
• Código ofuscado
• Prefactorización
• Reescribir (programación)
• Separación de preocupaciones
• Revisión de software por pares
• Desarrollo basado en pruebas

• Wake, William C. (2003). Manual de refactorización . Addison-Wesley. ISBN 978-0-321-10929-3.
• Mens, T.; Tourwe, T. (febrero de 2004). "Un estudio sobre la refactorización de software". IEEE Transactions on Software Engineering . 30 (2): 126–139. doi :10.1109/tse.2004.1265817. ISSN  0098-5589. S2CID  206778272.
• Feathers, Michael C (2004). Cómo trabajar eficazmente con código heredado . Prentice Hall. ISBN 978-0-13-117705-5.
• Kerievsky, Joshua (2004). Refactorización a patrones . Addison-Wesley. ISBN 978-0-321-21335-8.
• Arsenovski, Danijel (2008). Refactorización profesional en Visual Basic . Wrox. ISBN 978-0-470-17979-6.
• Arsenovski, Danijel (2009). Refactorización profesional en C# y ASP.NET . Wrox. ISBN 978-0-470-43452-9.
• Ritchie, Peter (2010). Refactorización con Visual Studio 2010. Packt. ISBN 978-1-84968-010-3.

• ¿Qué es la refactorización? (artículo de c2.com)
• Página de inicio de Martin Fowler sobre refactorización
• Refactorización en Curlie