Refactorización de código

En programación y diseño de software , la refactorización de código es el proceso de reestructurar el código fuente existente —cambiando su factorización— sin modificar su comportamiento externo. La refactorización busca mejorar el diseño, la estructura o la implementación del software (sus atributos no funcionales ), preservando su funcionalidad . Entre las posibles ventajas de la refactorización se incluyen una mayor legibilidad del código y una menor complejidad ; esto puede mejorar la mantenibilidad del código fuente y crear una arquitectura interna o un modelo de objetos más simple, limpio y expresivo para mejorar la extensibilidad . Otro objetivo potencial de la refactorización es la mejora del rendimiento; los ingenieros de software se enfrentan al reto constante de escribir programas más rápidos o que consuman menos memoria. A pesar de la disponibilidad de métricas para evaluar estos atributos, los desarrolladores a menudo no las utilizan al tomar decisiones de refactorización debido a la incertidumbre sobre su utilidad práctica. ^{[ 1 ]}

Por lo general, la refactorización aplica una serie de microrefactorizaciones básicas estandarizadas , cada una de las cuales consiste (normalmente) en un pequeño cambio en el código fuente de un programa informático que conserva el comportamiento del software o, al menos, no modifica su conformidad con los requisitos funcionales. Muchos entornos de desarrollo ofrecen soporte automatizado para realizar los aspectos mecánicos de estas refactorizaciones básicas. Si se realiza correctamente, la refactorización del código puede ayudar a los desarrolladores de software a descubrir y corregir errores o vulnerabilidades ocultas o latentes en el sistema, simplificando la lógica subyacente y eliminando niveles innecesarios de complejidad. Si se realiza incorrectamente, puede incumplir el requisito de que la funcionalidad externa no se modifique y, por lo tanto, puede introducir nuevos errores.

Al mejorar continuamente el diseño del código, facilitamos cada vez más su uso. Esto contrasta notablemente con lo que suele ocurrir: poca refactorización y mucha atención dedicada a añadir nuevas funcionalidades rápidamente. Si adquieres el hábito de refactorizar continuamente, verás que es más fácil ampliar y mantener el código.

La refactorización suele estar motivada por la detección de un código problemático . ^{[ 3 ]} Por ejemplo, el método en cuestión puede ser muy extenso o prácticamente idéntico a otro método cercano. Una vez identificados, estos problemas pueden abordarse refactorizando el código fuente o transformándolo en una nueva versión que se comporte igual que antes, pero que ya no presente ese problema.

Para una rutina larga, se pueden extraer una o más subrutinas más pequeñas. Para rutinas duplicadas, la duplicación se puede eliminar y reemplazar con una función compartida. No realizar la refactorización puede resultar en la acumulación de deuda técnica ; por otro lado, la refactorización es uno de los principales medios para saldar la deuda técnica. ^{[ 4 ]}

Existen dos categorías generales de beneficios derivados 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 comprender. ^{[ 5 ]} Esto se puede lograr reduciendo las rutinas monolíticas extensas a un conjunto de métodos concisos, bien nombrados y con un solo propósito. También 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 extender las capacidades de la aplicación si utiliza patrones de diseño reconocibles , y proporciona cierta flexibilidad donde antes no existía. ^{[ 2 ]}

La ingeniería de rendimiento puede eliminar las ineficiencias en los programas, conocidas como sobrecarga de software, que surgen de las estrategias tradicionales de desarrollo de software que buscan minimizar el tiempo de desarrollo de una aplicación en lugar del tiempo que tarda en ejecutarse. 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. ^{[ 6 ]}

Hay dos momentos posibles para refactorizar.

1. Refactorización preventiva: el desarrollador original del código lo hace más robusto cuando aún no tiene olores para evitar que se formen olores en el futuro. ^{[ 7 ]}
2. Refactorización correctiva: un desarrollador posterior realiza una refactorización para corregir los malos olores del código a medida que se producen. ^{[ 7 ]}

Un método que equilibra la refactorización preventiva y correctiva es la "responsabilidad compartida para 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 lo prepara para la refactorización, y cuando el código presenta problemas, un desarrollador posterior lleva a cabo la refactorización propiamente dicha. ^{[ 7 ]}

La refactorización requiere extraer la estructura del sistema de software, los modelos de datos y las dependencias internas de la aplicación para recuperar el conocimiento de un sistema de software existente. ^{[ 8 ]} La rotación de equipos implica un conocimiento incompleto o inexacto del estado actual de un sistema y de las decisiones de diseño tomadas por los desarrolladores que se marchan. Las actividades de refactorización de código posteriores pueden requerir un esfuerzo adicional para recuperar este conocimiento. ^{[ 9 ]} Las actividades de refactorización generan modificaciones arquitectónicas que deterioran la arquitectura estructural de un sistema de software. Dicho deterioro afecta a propiedades arquitectónicas como la mantenibilidad y la comprensibilidad, lo que puede llevar a un rediseño completo de los sistemas de software. ^{[ 10 ]}

Se deben configurar pruebas unitarias automáticas antes de la refactorización para asegurar que las rutinas sigan comportándose como se espera. ^{[ 11 ]} 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 abarcan varios proyectos es almacenar todos los proyectos en un único repositorio , conocido como monorepo . ^{[ 12 ]}

Con las pruebas unitarias implementadas, la refactorización se convierte en un ciclo iterativo que consiste en realizar una pequeña transformación del programa , probarla para asegurar su corrección y realizar otra pequeña transformación. Si en algún momento falla una prueba, se deshace el último cambio y se repite de otra manera. Mediante muchos pasos pequeños, el programa pasa de su estado inicial al deseado. Para que este proceso 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. Los defensores de la programación extrema y otros métodos ágiles de desarrollo de software describen esta actividad como una parte integral del ciclo de desarrollo de software . La refactorización se aplica tanto al código de prueba como al código de producción; los estudios empíricos muestran que la refactorización de pruebas se centra principalmente en el código de prueba de baja calidad que presenta malas prácticas , y mejora el acoplamiento, la cohesión y el tamaño del código de prueba, aunque no necesariamente mejora la cobertura del código. ^{[ 13 ]}

Aquí se muestran algunos ejemplos de microrefactorizaciones; algunas de ellas pueden aplicarse únicamente a ciertos lenguajes o tipos de lenguaje. Una lista más extensa se puede encontrar en el libro de refactorización de Martin Fowler ^{[ 3 ]} y en su sitio web ^{[ 14 ]} . Muchos entornos de desarrollo ofrecen soporte automatizado para estas microrefactorizaciones. Por ejemplo, un programador podría hacer clic en el nombre de una variable y seleccionar la refactorización "Encapsular campo" en el menú contextual . El IDE solicitaría entonces información adicional, generalmente con valores predeterminados adecuados y una vista previa de los cambios en el código. Tras la confirmación del programador, se realizarían los cambios necesarios en todo el código.

Si bien el término refactorización se refería originalmente 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 una forma abreviada de referirse a 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 los lenguajes de descripción de hardware como lenguajes de programación , ^{[ 20 ]} la refactorización de hardware debe considerarse un campo independiente 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 mejora no funcional radica en que el código refactorizado puede ser procesado por herramientas de síntesis estándar, mientras que el código original no. Mike Keating, miembro de Synopsys , también investigó la refactorización de lenguajes de descripción de hardware digital, aunque de forma manual. ^{[ 22 ] [ 23 ]} Su objetivo es simplificar la comprensión de sistemas complejos, 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 hecho informalmente durante décadas, la disertación doctoral de William Griswold de 1991 ^{[ 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 William Opdyke de 1992 ^{[ 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 se debe (o no se debe) aplicar el método.

El libro de Martin Fowler, Refactoring: Improving the Design of Existing Code, es la referencia canónica.

Los términos "factoring" y "factoring out" se han utilizado de esta manera en la comunidad Forth desde al menos principios de la década de 1980. El capítulo seis del libro de Leo Brodie , Thinking Forth (1984) ^{[ 28 ]} , está dedicado al tema.

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

Las refactorizaciones también pueden reconstruirse ^{[ 29 ]} a posteriori para producir descripciones concisas de cambios de software complejos registrados en repositorios de software como Git .

Muchas herramientas de desarrollo de software cuentan con funciones para la refactorización. Algunos ejemplos son:

Android Studio

Admite la refactorización de Java y C++.

Código de aplicación

Admite la refactorización de Objective-C , C y C++.

Delfos

Admite la refactorización de Object Pascal .

Kit de herramientas para la reingeniería de software de DMS

Admite la refactorización a gran escala para C , C++ , C# , COBOL , Java , PHP y otros lenguajes.

Eclipse

Mediante complementos, admite la refactorización de Java y, en menor medida, de C++, PHP, Ruby y JavaScript.

IntelliJ IDEA

Admite la refactorización de Java.

JDeveloper

Admite la refactorización de Java.

NetBeans

Admite la refactorización de Java.

PhpStorm

Admite la refactorización de PHP.

PyCharm

Admite la refactorización de Python.

PyDev

Admite la refactorización de Python .

Charla informal

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 90 por Ralph Johnson .

Asistencia visual

Admite la refactorización de C# y C++.

Visual Studio

Admite la refactorización de .NET y C++.

Código de Visual Studio

Admite la refactorización de muchos lenguajes mediante complementos.

WebStorm

Admite la refactorización de JavaScript.

Wing IDE

Admite la refactorización de Python.

Xcode

Admite la refactorización de C, Objective-C y Swift . ^{[ 30 ]}

Creador de Qt

Admite la refactorización de 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 intereses
• Revisión por pares de software
• desarrollo guiado por pruebas

• Wake, William C. (2003). Refactoring Workbook . Addison-Wesley. ISBN 978-0-321-10929-3.
• Mens, T.; Tourwe, T. (febrero de 2004). "Una revisión de la refactorización de software" . IEEE Transactions on Software Engineering . 30 (2): 126– 139. Bibcode : 2004ITSEn..30..126M . doi : 10.1109/tse.2004.1265817 . ISSN 0098-5589 . S2CID 206778272 .  
• Feathers, Michael C. (2004). Trabajar eficazmente con código heredado . Prentice Hall. ISBN 978-0-13-117705-5.
• Kerievsky, Joshua (2004). Refactoring To Patterns . 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). Refactoring with Visual Studio 2010. Packt. ISBN 978-1-84968-010-3.

• ¿Qué es la refactorización? (Artículo de c2.com)
• Página principal de Martin Fowler sobre refactorización