refactoring - sinonimo - Objetivos de refactorización?
refactorizar sinonimo (15)
¿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?
¿Tiempo pasado?
En serio, lo hago para:
- evitar la duplicación de código cuando lo veo (siguiendo el principio DRY )
- simplifique el código (elimine las complejidades ad-hoc innecesarias, vea KISS )
- eliminar código viejo / obsoleto / en desuso (desechos de limpieza, una vez que se reemplaza el código anterior)
- eliminar los efectos secundarios
- generalizar y reutilizar el código existente
- Para eliminar / reducir el "Código huele"
- Más fácil para cualquier desarrollador comprender el código
- Para que sea mantenible
- Para aumentar la cohesión y reducir el acoplamiento "
En general, solo refactorizaría 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 en unidades más fácilmente, luego realicé los cambios para poder volver a ejecutar las pruebas y muestran que funcionó como antes.
El código de refactorización que no necesita ser cambiado es una receta para el desastre; está garantizado para introducir errores.
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 individuo sea responsable de refactorizar el código en cualquier lugar, no solo el código escrito por él mismo (o coescrito).
La refactorización puede tener múltiples incentivos:
- mejorar la legibilidad del código
- simplificar la estructura del código
- mejorar la capacidad de mantenimiento
- mejorar la extensibilidad
La razón para comenzar a refactorizar generalmente depende de los problemas que haya tenido.
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 facilitar que los desarrolladores rastreen los errores.
A veces, los errores provienen de una función / clase / ... que no se usó como se pretendía. Esto indica que el código no era fácil de entender o estaba mal documentado.
Ahora, si mejora la documentación, la legibilidad del código y la estructura del código, también obtendrá un mejor mantenimiento ...
La refactorización se usa para pagar su deuda técnica .
La refacturación de código 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 necesaria la refactorización:
- Introducción de una nueva regla comercial que requiere que el diseño actual se abstraiga a un nuevo nivel;
- Reconocimiento del hecho de que el diseño actual podría modificarse para observar mejor los principios SOLIDOS del diseño orientado a objetos;
- Cuando se necesita aumentar la capacidad de prueba del código, esto se relaciona con 2 arriba.
Normalmente no refactorizo el código solo para reducir los olores del código, o hacerlo ''más agradable'' / más fácil de mantener. Hago una refactorización, cuando necesito reparar el error, y quiero dejar el código en mejor forma que antes. Otra razón es cuando quiero agregar funcionalidad, y sería difícil hacerlo sin refactorizar. El tercer motivo es hacer que el código sea más comprobable. A veces me refactorizo para aprender el código que no entiendo :-)
Para reducir el costo del cambio
Organización.
Por supuesto, cuando esté seguro de que nunca tendrá que volver a tocar un trozo 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.
- reducir la complejidad de las funciones individuales: hace que las pruebas sean más fáciles
- eliminando el código repetido - reduce las oportunidades de errores
En resumen ... Para deshumedecer el código.
Para mí: rendimiento .
Comprensibilidad
Un código más directo y bien organizado (factorizado) es más fácil de entender.
Exactitud
Es más fácil identificar los defectos mediante inspección en un 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
Los componentes comunes bien definidos, de alta calidad y fáciles de entender 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.
El código de refactorización tiene mérito solo en términos de calidad de código y problemas de corrección, pero donde la refactorización es más rentable es 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 refactoreo / rediseño de ventajas hipotéticas "tajo en el cielo" que es difícil de justificar a la gerencia.