¿Se refactoriza en pequeños pasos?

Question

Después de leer "Refactorización" de Fowler por un tiempo, a menudo me sorprendo pensando "Debería haber hecho esto en pasos más pequeños". - Incluso cuando no rompí mi código.

Refactorear en pequeños pasos es seguro, pero cuesta tiempo. Es una compensación entre la velocidad y el riesgo: trato de ser estratégico al elegir la forma en que estoy refabricando.

Sin embargo: La mayoría del tiempo estoy haciendo refactorizaciones en pasos más grandes. Si tomo parte de la sección "Mecánica" de Fowler y comparo cómo estoy trabajando, tal vez descubro que a menudo doy dos o cinco pasos al mismo tiempo. Esto no significa que soy un gurú de refactorización. Mi código puede permanecer entre 5 y 60 minutos roto o no disponible.

¿Se refactoriza en pasos más pequeños y trata de producir código continuo en frecuencias más cortas? Y: ¿Eres exitoso en hacer esto?

Answer 1

Martin Fowler parece inclinarse hacia el enfoque de refactorización pequeño y gradual. Sin embargo, después de leer su libro ocasionalmente realiza algunos pasos drásticos, pero solo con pruebas unitarias para respaldar el código.

La refabricación es una técnica controlada para mejorar el diseño de una base de códigos 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. - Martin Fowler

Answer 2

Tiendo a refactorizar en grandes pasos la mayor parte del tiempo para poder ver el bosque desde los árboles. Es un tipo de programación de "flujo de conciencia". Siempre que tenga su última versión de trabajo segura en el control de origen de su elección ...

Answer 3

que es donde el enfoque "rojo, verde, refactor" es útil. En cada etapa, usted tiene la capacidad de verificar que el comportamiento de su código no se modifique, y la refactorización solo tiene que integrar el nuevo comportamiento.

Answer 4

Lo intento :) El único impulso que tengo que resistir más mientras refactoreo es en realidad hacer otros cambios en el camino. Digamos que estoy refabricando un código y veo algo que no está relacionado en el código. Tengo que hacer un esfuerzo consciente para no ir a "arreglarlo" también. Toma nota y sigue adelante. Por un lado, es una distracción de la tarea en cuestión. También termina contaminando su conjunto de cambios por lo que su mensaje de compromiso ahora tiene que documentar varios cambios aparentemente aleatorios.

Answer 5

La regla de oro que uso es refactor con pruebas y solo refactoriza tanto código como usted confía también.

A los 60 minutos, está seguro de que su código está haciendo exactamente lo que debería. Necesitarías muchas pruebas para aprobar. Solo intentaría ponerme en funcionamiento y pasar al siguiente.

Answer 6

Si tengo una idea clara de lo que quiero hacer, y si puedo verificar fácilmente que no he roto nada después, estoy dando pasos más grandes.

Si la refactorización es más complicada, trato de dividirla en pasos más pequeños y realizar pruebas exhaustivas después de cada una.

Answer 7

Sí, siempre. Creo que la verdadera esencia de la refactorización es elegir qué pasos comenzar.

Encuentro que la refacturación de grandes cambios de una manera segura es siempre para tener una imagen razonablemente clara de hacia dónde desea ir. Luego, considere su sistema existente y trate de descubrir qué piezas puede presentar que tienen la menor probabilidad de ser un cambio radical. Luego puede presentarlos de una manera controlada y bien probada.

Así que lo que haces es trabajar en las cercanías de la maldad. No siempre ataca directamente desde el frente, pero a veces solo corta piezas pequeñas. Por lo general, espero y solo voy por el "gran premio" después de unas cuantas rondas de astucia de poca monta. Pero sé donde quiero ir.

Lo bueno de trabajar de esta manera es que se puede mantener el progreso. Nunca "paras el desarrollo para hacer refactorización". Podría decirse que hay casos en los que detenerse es la situación correcta, pero la mayoría de las veces no lo es.

La idea aquí es que si "comienzas" a cobrar el dinero del premio, pasarás los próximos X días haciendo el trabajo pesado. Y existe el riesgo, tal vez te asustes o no funcione, o pases 6 meses en lugar de una semana. Si primero haces el trabajo pesado, cambiar el premio será posible con menos riesgo. Y su código mejorará a medida que avanza. A veces puede decidir que hacer la mitad del trabajo fue suficiente, ya que su comprensión del problema aumenta. A veces, su idea de dónde quería ir fue un poco fallida, y puede realinear su objetivo a medida que avanza.

Pero es tentador ir directo a la recompensa.

Answer 8

Normalmente refactorizo ​​el código cuando lo cambio. Es decir, en lugar de tomar un fragmento de código y reescribirlo mientras mantengo su función, lo reescribo para una nueva funcionalidad y en el proceso de hacerlo, mejoro el diseño del código.

A menudo, esto significa que cuando implementé la función que estaba buscando no he realizado una refacturación completa y satisfactoria del código anterior. Sin embargo, ha mejorado, y sé que tendré tiempo de mejorarlo la próxima vez que esté a punto de cambiar su función.

Para probar esto significa que puedo probar tanto la refactorización como la nueva función al mismo tiempo, lo que debería ahorrar algo de tiempo.

También significa que solo paso el tiempo suficiente en la refactorización para mejorar la situación de mantenimiento requerida para esa característica en particular. Esto debería ayudar a evitar el exceso de ingeniería y/o perder el tiempo refabricando cosas que ya funcionan y que no se beneficiarán de un mejor diseño. Al centrarme solo en el código, cambiaría de todos modos, también hay una gran probabilidad de que vuelva a visitar ese código en el corto plazo para hacer más cambios mientras está en el lapso de atención de los usuarios.

Answer 9

Pequeños pasos discretos es con lo que me siento más cómodo, aunque en algunos puntos puede ser una prueba de mi autocontrol para reinar en lo que podría ser un baño de sangre refactorizado. Si noto alguna mejora (no importa cuán grande) podría hacerse, tomo nota de ellos y considero cómo se dividiría en tareas de refactorización individuales. Además, tener una saga de cambios en el mensaje de compromiso no ayuda.

NB. La base de código con la que trabajo es bastante antigua y está llena de errores místicos que llevan el nombre de científicos. Con porciones grandes que aún carecen de algo que esté cerca de una cobertura de prueba del 50%, sería descuidado dejarse llevar.

Answer 10

Yep. Me gusta ejecutar las pruebas continuamente, por lo que una cadena de pequeños refactores funciona bien.Me pongo muy incómodo tener mi código roto por más de unos pocos minutos a la vez, y en general puedo volver si mi código se rompe cuando voy a casa por la noche, la re-escribir la mañana siguiente siempre funciona mejor que tratar de continuar donde Yo era.