refactoring - software - refactory
¿Qué es refactorizar y qué es solo código de modificación? (10)
Con la definición de Martin Fowler en mente,
Refactorizar es una técnica disciplinada para reestructurar un cuerpo existente de código, alterando su estructura interna sin cambiar su comportamiento externo.
... Creo que tienes razón.
También sugirieron cosas como cambiar las estructuras de datos (como Java LinkedList a ArrayList), cambiar los algoritmos (usar merge sort en lugar de bubble sort) e incluso reescribir grandes fragmentos de código como refactorización.
¡Cambiar un algoritmo a algo mucho más rápido obviamente no es refactorizar, porque el comportamiento externo ha cambiado! (Por otra parte, si el efecto nunca se nota, tal vez podría llamarlo refactorización después de todo, y también una optimización prematura. :-)
Esta es una manía mía; es molesto cuando la gente usa el término de manera descuidada; incluso me he encontrado con algunos que podrían usar la refactorización casualmente para cualquier tipo de cambio o solución. Sí, es una palabra de moda y genial, pero no hay nada de malo con los viejos términos simples como cambiar , reescribir o mejorar el rendimiento . Deberíamos utilizarlos cuando corresponda, y reservar la refactorización para los casos en los que realmente solo está mejorando la estructura interna de su software. Dentro de un equipo de desarrollo, especialmente, tener un lenguaje común para discutir con precisión su trabajo sí importa.
Sé que refactorizar es "cambiar la estructura de un programa para que la funcionalidad no se modifique". Estuve hablando con algunos de los muchachos con los que estoy trabajando en mi proyecto de último año en la universidad y me sorprendió que tuvieran una visión mucho más expansiva (a falta de una mejor palabra) de refactorización.
Considero refactorizar cosas como extraer métodos y renombrar clases. También sugirieron cosas como cambiar las estructuras de datos (como Java LinkedList a ArrayList ), cambiar los algoritmos (usar merge sort en lugar de bubble sort) e incluso reescribir grandes fragmentos de código como refactorización.
Estaba bastante seguro de que estaban equivocados, pero no pude dar una buena razón porque lo que estaban sugiriendo cambió el programa (y, presumiblemente, lo mejoró) sin cambiar su comportamiento. Estoy en lo cierto, y lo más importante, ¿por qué?
Creo que nadie puede beneficiarse de una definición demasiado fuerte del término ''refactorización''. El límite entre cómo lo percibes y tus colegas es borroso y puede estar más cerca de ellos o de tu vista, dependiendo de muchos factores. Como es dinámico, intentemos definirlo. En primer lugar, defina los límites del sistema o subsistema que está tratando de refactorizar.
Si se trata de un método, mantenga fijos el nombre, los argumentos de entrada, el tipo del valor devuelto y posiblemente las sentencias de lanzamiento. Aplique todos los cambios dentro del método sin cambiar la forma en que se ve afuera.
Si refactoriza una clase, arregla su API pública y usa variables de cambio de nombre, extrae métodos y todas las otras técnicas disponibles cambian la clase para que sea más legible y / o más eficiente.
Si la parte del código que está refactorizando es un paquete o un módulo, haga la refactorización dentro de este, posiblemente cambiando el nombre de las clases, eliminando, introduciendo interfaces, empujando / arrastrando el código hacia superclases / subclases.
Creo que tienes razón, pero discutir el significado de una palabra no es particularmente interesante o productivo.
Fowler traza una línea limpia entre los cambios al código que sí lo hacen, y los que no, afectan su comportamiento. Él llama a los que no lo hacen, "refactorización". Esta es una distinción importante, porque si dividimos nuestro trabajo en actividades de modificación del código de refactorización y no refactorización (Fowler lo llama "usar sombreros diferentes"), podemos aplicar diferentes técnicas apropiadas para cada objetivo.
Si realizamos una modificación del código de refactorización o preservación del comportamiento:
- todas nuestras pruebas unitarias deben pasar antes y después de la modificación
- no deberíamos necesitar modificar ninguna prueba, ni escribir ninguna nueva
- esperamos un código más limpio cuando hayamos terminado
- no esperamos un nuevo comportamiento
Si estamos haciendo una modificación del código que cambia el comportamiento:
- esperamos un nuevo comportamiento
- deberíamos escribir nuevas pruebas
- podemos obtener un código más sucio cuando hayamos terminado (y luego debemos refactorizarlo)
Si perdemos de vista esta distinción, entonces nuestras expectativas para cualquier tarea de modificación de código dada son confusas y complejas, o en cualquier caso más confusas y más complejas que si somos conscientes de ello. Es por eso que la palabra y su significado son importantes.
No estoy de http://en.wikipedia.org/wiki/Code_refactoring
En ingeniería de software, "refactorizar" el código fuente significa mejorarlo sin cambiar sus resultados generales [...]
Ya conoce los términos más precisos que se usan para subconjuntos de refactorización, y sí, es un término muy general.
Para dar mi opinión:
Pequeños cambios incrementales que dejan el código en un mejor estado que el que se encontró
Definitivamente Sí: cambios "cosméticos" que no están directamente relacionados con las características (es decir, no se pueden facturar como solicitud de cambio).
Definitivamente no: la reescritura de grandes fragmentos claramente viola la parte "pequeña, incremental". La refactorización se usa a menudo como lo opuesto a una reescritura: en lugar de hacerlo de nuevo, mejore la existente.
Definitivamente tal vez: reemplazar las estructuras de datos y los algoritmos es algo así como un caso de frontera. La diferencia decisiva aquí OMI es los pequeños pasos: estar listo para entregar, estar listo para trabajar en otro caso.
Ejemplo: imagine que tiene un módulo de informe de aleatorizador que se ralentiza mediante el uso de un vector. Usted ha perfilado que las inserciones vectoriales son el cuello de botella, pero desafortunadamente el módulo se basa en la memoria contigua en muchos lugares, de modo que cuando se usa una lista, las cosas se rompen silenciosamente.
Reescribir significaría tirar el Módulo a un edificio mejor y más rápido desde cero, simplemente escogiendo algunas piezas del anterior. O escribiendo un nuevo núcleo, luego colocándolo en el diálogo existente.
Refactorizar significaría tomar pequeños pasos para eliminar la aritmética del puntero, de modo que el interruptor. Tal vez incluso crees una función de utilidad envolviendo los aritméticos del puntero, reemplazando la manipulación del puntero directo con llamadas a esa función, luego cambias a un iterador para que el compilador se queje de los lugares donde aún se usan los aritméticos del puntero, luego cambia a una list y luego elimina la función de la superioridad
La idea detrás es que el código empeora por sí mismo. Al corregir errores y agregar características, la calidad decae en pequeños pasos: el significado de una variable cambia sutilmente, una función obtiene un parámetro adicional que rompe el aislamiento, un ciclo se vuelve un poco complejo, etc. Ninguno de estos es un error real, usted puede No diga un recuento de líneas que hace que el ciclo sea complejo, pero perjudica la legibilidad y el mantenimiento.
Del mismo modo, cambiar un nombre de variable o extraer una función no son mejoras tangibles propias. Pero, en conjunto, luchan contra la lenta erosión.
Como una pared de guijarros donde todos los días uno cae al suelo. Y todos los días, un transeúnte lo recoge y lo devuelve.
Si desea leer algunos consejos sobre por qué la refacturación es importante y por qué siempre debe estar insatisfecho con su trabajo anterior, le puedo recomendar la nueva publicación del blog. Contestará algunas preocupaciones sobre refactorización, cómo convencer a su jefe de que es importante, etc.
Si la interfaz de un fragmento de código cambia, entonces lo considero más que una refactorización.
El caso típico para la refactorización es
- "Oh, todas las pruebas de mi unidad se ejecutan, pero creo que mi código podría estar más limpio"
- Cambiar código para ser más legible / claro / eficiente
- Vuelva a ejecutar las pruebas unitarias (sin cambiar las pruebas) y compruebe que todavía funcionen
Esto significa que el término refactorización es relativo a la interfaz que está discutiendo. es decir, podría estar refactorizando el código detrás de una interfaz, mientras que cambiaría más extensamente el código de otra en un nivel inferior (tal vez esa distinción es la que está generando confusión entre usted y sus colegas).
http://en.wikipedia.org/wiki/Code_refactoring
Refactorización de código es el proceso de cambiar la estructura interna de un programa de computadora sin modificar su comportamiento funcional externo o funcionalidad existente, para mejorar las propiedades internas no funcionales del software, por ejemplo para mejorar la legibilidad del código, simplificar la estructura del código, cambiar el código adherirse a un paradigma de programación dado, mejorar la mantenibilidad, mejorar el rendimiento o mejorar la extensibilidad.
Estoy de acuerdo en que el código de refactorización incluye romper el código existente. Solo asegúrate de tener pruebas unitarias para que no introduzcas ningún error y compila el resto del código. ¡Usar herramientas de refactorización como Resharper for C # hace que esto sea tan fácil!
- Hacer el código más comprensible
- Limpiar el código y hacerlo más ordenado
- Eliminando el código! El código y los comentarios redundantes no utilizados deben eliminarse
- Mejorando el desempeño
- Hacer algo más genérico. Comience con lo más simple posible, luego refactorícelo para que sea más fácil de probar / aislar o genérico para que pueda funcionar de diferentes maneras a través del polimorfismo.
- Cómo mantener el código SECO: no se repita, por lo que una sesión de refactorización podría implicar tomar algún código repetido y refactorizarlo en un solo componente / clase / módulo.
"Refactorización: Mejorando el Diseño del Código Existente" de Martin Fowler es quizás LA referencia:
La refactorización es una técnica controlada para mejorar el diseño de una base de código existente. Su esencia es aplicar una serie de pequeñas transformaciones para preservar el comportamiento, cada una de las cuales es "demasiado pequeña para que valga la pena". Sin embargo, el efecto acumulativo de cada una de estas transformaciones es bastante significativo. Al hacerlo en pequeños pasos, reduce el riesgo de introducir errores. También evitará que se rompa el sistema mientras lleva a cabo la reestructuración, lo que le permite refactorizar gradualmente un sistema durante un período de tiempo prolongado.
La refactorización va de la mano con la prueba unitaria. Escriba pruebas antes de refactorizar y luego tenga un nivel de confianza en la refactorización (proporcional a la cobertura de las pruebas).
Una buena referencia es: Información sobre refactorización