2009-01-31 20 views
9

¿Cuáles son los objetivos del código de refactorización? ¿Es solo para mejorar la estructura del código? ¿Prepara el camino para futuros cambios?Objetivos de refactorización?

+0

Pregunta similar en StackOverflow http://stackoverflow.com/questions/128498/what-are-the-best-code-refactoring-strategies – Vinay

Respuesta

15

Comprensibilidad

(multiplicada) código más sencillo y bien organizado es más fácil de entender.

corrección

Es más fácil identificar defectos mediante inspección en código que es más fácil de entender. El código de estilo Rube Goldberg demasiado complejo y poco estructurado es mucho más difícil de inspeccionar en busca de defectos. Además, un código bien compuesto con una alta coherencia de los componentes y un acoplamiento flexible entre los componentes es mucho más fácil de poner a prueba. Además, los bits más pequeños y bien formados bajo prueba hacen que haya menos solapamiento en la cobertura del código entre los casos de prueba, lo que hace que las pruebas sean más rápidas y confiables (lo que se convierte en un ciclo de autorrefuerzo hacia pruebas cada vez mejores). Además, el código más directo tiende a ser más predecible y confiable.

Facilidad de mantenimiento y evolución

factorizado bien, de alta calidad, fácil de entender los componentes comunes son más fáciles de usar, extender y mantener. Muchos cambios en el sistema ahora son más fáciles de hacer porque tienen un impacto menor y es más obvio cómo hacer los cambios apropiados.


código de refactorización tiene mérito por sí solo en términos de calidad del código y problemas de corrección, pero donde refactorización paga la mayor parte está en el mantenimiento y la evolución del diseño del software. A menudo, una buena táctica cuando se agregan nuevas características al código viejo y mal factorizado es refactorizar el código objetivo y luego agregar la nueva característica. A menudo, esto requerirá menos esfuerzo de desarrollo que tratar de agregar la nueva función sin refactorizar y es una forma útil de mejorar la calidad de la base de código sin emprender una gran cantidad de trabajos de refacturación/rediseño de ventajas hipotéticas "tajo en el cielo" que es difícil de justificar a la gerencia.

+0

Si la gerencia no entiende los problemas de diseño, ¿por qué sería difícil justificarlo? Simplemente discute la justificación en términos de beneficios a largo plazo y otros tipos de pelusas para sentirse bien. –

+0

@Eric Smith: Porque la administración puede ser miope en estos asuntos. No ven ningún beneficio inmediato de la refactorización (la funcionalidad no cambia), por lo que no desean tiempo ni esfuerzo en ello. –

0
  • reducir la complejidad de las funciones individuales - hace que las pruebas más fácil
  • eliminación de código repetidos - reduce las oportunidades de errores
2
  1. para eliminar/reducir el "Código huele"
  2. más fácil para cualquier desarrollador para comprender el código
  3. Para que sea fácil de mantener.
  4. Para aumentar la cohesión y para reducir el acoplamiento"
+0

Debería ser: "4: para aumentar la cohesión y reducir el acoplamiento". –

+0

Error tipográfico solucionado – Vinay

1

No suelo refactorizar código sólo para reducir los olores de código, o hacerla 'más bonita'/más fácil de mantener. Refactor que hago, cuando necesito corrección de errores , y quiero dejar el código en una mejor forma que antes. Otra razón es cuando quiero agregar funcionalidad, y sería difícil hacerlo sin refactorizar. La tercera razón es hacer que el código sea más comprobable. A veces me refactorizo ​​para aprender el código que no entiendo :-)

+0

¿Seguro que necesita comprenderlo para poder refactorizarlo? –

+0

Lo que quiero decir aquí es, por ejemplo, extraer código común del método largo una vez que sé lo que hace. O introducir variables cuando descubro qué expresión grande se supone que debe expresar. –

1

En un nivel muy básico, el objetivo es mejorar el código, haciéndolo más legible, menos acoplado, disminuyendo las tasas de error, y así sucesivamente.

En otro nivel, la refactorización surgió como una alternativa a BigUpfrontDesign. Además, cuando se utiliza en contextos tales como Extreme Programming, la refactorización es un deber. Paga hipoteca en sus depósitos técnicos todos los días, cada hora. Junto con los principios como propiedad del código colectivo, también hace que cada persona sea responsable de refactorizar el código en cualquier lugar, no solo el código escrito por uno mismo (o co-escrito).

0

Refactoring puede tener múltiples incentivos:

  • mejorar la legibilidad del código
  • simplificar la estructura del código
  • mejorar la mantenibilidad
  • mejorar la extensibilidad

La razón para empezar refactorización por lo general depende de la problemas con los que te encontraste

Si amplía su software y se topa con errores y no puede encontrar el origen de los errores, entonces puede comenzar a refactorizar para simplificar la estructura del código a fin de que sea más fácil para los desarrolladores rastrear errores.

A veces los errores provienen de una función/clase/... que no se utilizó como estaba previsto. Esto indica que el código no era fácil de entender o estaba mal documentado.

Ahora, si se mejora la documentación, la legibilidad del código y la estructura del código también puede contribuir a una mejor capacidad de mantenimiento ...

0

Por supuesto, cuando esté seguro de que usted nunca tendrá siempre para volver a tocar un fragmento de código, no hay necesidad de refactorizar ese código.

Pero la mayoría de las veces, tendrá que volver a tocarlo porque tendrá que agregar funciones, corregir errores u optimizarlo.

Por lo tanto, sí, por supuesto, es para allanar el camino para futuros cambios. El código siempre cambia.

1

La refabricación de códigos es una necesidad de observar el hecho de que el cambio es inevitable. Su objetivo principal es mejorar el código o el diseño actual para hacerlo compatible y congruente con los nuevos requisitos funcionales o no funcionales o para que sea más tolerante al cambio.

ejemplos de escenarios en los que puede ser necesario refactorización:

  1. La introducción de una nueva regla de negocio que requiere el diseño actual para ser abstraído a un nuevo nivel;
  2. Reconocimiento del hecho de que el diseño actual podría modificarse para observar mejor los principios SOLID del diseño orientado a objetos;
  3. Cuando se necesita aumentar la capacidad de prueba del código --- esto se relaciona con el 2 anterior.
0

Para reducir el costo del cambio.

0

En general, solo volvería a factorizar el código de producción para reutilizarlo o cuando se requieran modificaciones.

Por ejemplo, necesitaba actualizar una función por razones de rendimiento, pero no había una interfaz de prueba fácil, así que la rediseñé en un módulo separado que podría ser probado de forma más sencilla, luego realicé los cambios para que podría volver a ejecutar las pruebas y mostrar que funcionó como antes.

El código de refacturación que no necesita ser cambiado es una receta para desastres; está garantizado para introducir errores.

+0

refactoring está cambiando la estructura del código sin cambiar el comportamiento. Para eso necesitas pruebas unitarias al menos. si no lo prueba, simplemente está cambiando un código que no está refactorizando. – Nazgob

+0

Estrictamente hablando, cambiar las cosas que no necesitan cambios simplemente reemplaza los viejos errores por otros nuevos. Algunas veces esto parece presentar errores. Si tiene buenas pruebas (pocos errores antiguos), entonces el nuevo código aún debería ser correcto. Si no tiene buenas pruebas, entonces el código anterior probablemente tenía errores de todos modos ... –

1

Objetivos de la refactorización?

Passtime?

serio, lo hago para:

  • evitar la duplicación de código cuando la veo (siguiendo DRY principio)
  • simplificar el código (quitar complejidades ad-hoc innecesarios, ver KISS)
  • remove Código antiguo/obsoleto/en desuso (desperdicio de limpieza, una vez que se reemplaza el código anterior)
  • eliminar los efectos secundarios
  • generalizar y reutilizar el código existente
0

Organización.

0

En resumen ... Para deshumedecer el código.