¿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?
Respuesta
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.
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. –
@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. –
- 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
- para eliminar/reducir el "Código huele"
- más fácil para cualquier desarrollador para comprender el código
- Para que sea fácil de mantener.
- Para aumentar la cohesión y para reducir el acoplamiento"
Debería ser: "4: para aumentar la cohesión y reducir el acoplamiento". –
Error tipográfico solucionado – Vinay
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 :-)
¿Seguro que necesita comprenderlo para poder refactorizarlo? –
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. –
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).
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 ...
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.
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:
- La introducción de una nueva regla de negocio que requiere el diseño actual para ser abstraído a un nuevo nivel;
- Reconocimiento del hecho de que el diseño actual podría modificarse para observar mejor los principios SOLID del diseño orientado a objetos;
- Cuando se necesita aumentar la capacidad de prueba del código --- esto se relaciona con el 2 anterior.
Refactorización se utiliza para pagar su Technical Debt.
Para reducir el costo del cambio.
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.
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
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 ... –
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
Organización.
Para mi: Rendimiento.
En resumen ... Para deshumedecer el código.
- 1. refactorización prematura?
- 2. Refactorización: cómo evitar que se muestre la pestaña de refactorización.
- 3. UISegmentedControl y agregar objetivos
- 4. Makefile con objetivos múltiples
- 5. Objetivos opcionales en Cmake
- 6. herramientas de refactorización Java
- 7. Refactorización de autoconjunto
- 8. Refactorización de una clase
- 9. Refactorización de esquemas XSD
- 10. Acerca de la refactorización
- 11. Calling objetivos Maven de Java
- 12. Métricas para medir la refactorización exitosa
- 13. ¿Cómo agrupar objetivos en Phing?
- 14. Cómo comparar 2 objetivos Xcode
- 15. objetivos vacíos en m2eclipse (MAVEN)
- 16. Refactorización anidada para bucles
- 17. Refactorización "incluye archivo infierno"
- 18. Datos empíricos sobre refactorización?
- 19. Capistrano: archivo deploy.rb refactorización
- 20. Origen de la palabra Refactorización
- 21. Refactorización de declaración foreach anidada
- 22. Refactorización de JavaScript en Vim
- 23. Refactorización en Emacs
- 24. Erlang: refactorización sencilla
- 25. ejecutivo Ant refactorización
- 26. variable C argumento refactorización
- 27. Refactorización en Ruby
- 28. NetBeans PHP - refactorización
- 29. ¿Es posible excluir algunos objetivos de los objetivos Ant al ejecutar el script?
- 30. MSBUILD: Obtienen el directorio actual de objetivos
Pregunta similar en StackOverflow http://stackoverflow.com/questions/128498/what-are-the-best-code-refactoring-strategies – Vinay