refactoring - sinonimo - ¿Con qué frecuencia deberías refactorizar?
refactorizar sinonimo (25)
Tuve una discusión hace unas semanas con algunos compañeros de trabajo sobre refactorización, y parezco ser una minoría que cree que "Refactorizar temprano, refactorizar a menudo" es un buen enfoque que evita que el código se vuelva desordenado y no se pueda mantener. Varias otras personas pensaron que solo pertenece a las fases de mantenimiento de un proyecto.
Si tiene una opinión, defiéndala.
Absolutamente tan pronto como parezca conveniente. Si no lo haces, el dolor se acumula.
Desde que me cambié a Squeak (que ahora menciono en cada publicación) me he dado cuenta de que muchas de las preguntas de diseño durante la creación de prototipos caen porque la refacturación es muy fácil en ese entorno. Para ser sincero, si no tienes un entorno donde la refactorización es básicamente indolora, te recomiendo que pruebes chirrido solo para saber cómo puede ser.
Cada vez que encuentras una necesidad. Al menos cuando va a cambiar una pieza de código que necesita refactorización.
Como dice el libro, Usted refactoriza cuando
- agregas un código ... una nueva característica
- cuando arreglas un error / defecto
- cuando haces una revisión de código con varias personas
- cuando te encuentras duplicando algo por tercera vez. 3 regla de strikes
Como dijiste: refactoriza temprano, refactoriza a menudo.
Refactorizar temprano significa que los cambios necesarios todavía están frescos en mi mente. Refactorizar a menudo significa que los cambios tienden a ser más pequeños.
Retrasar la refacturación solo termina haciendo un gran desastre que además hace que sea más difícil refactorizar. Limpiar tan pronto como note el desorden evita que se acumule y se convierta en un problema más adelante.
Continuamente, dentro de lo razonable. Siempre debe buscar maneras de mejorar su software, pero debe tener cuidado para evitar situaciones en las que se está refaccionando para refactorizar (refactorización).
Si puede argumentar que una refactorización hará que un fragmento de código sea más rápido, más fácil de leer, más fácil de mantener o más fácil, o proporcionará algún otro valor para el negocio, ¡digo que sígalo!
Creo que deberías refacturar algo cuando actualmente trabajas en una parte. Significa que si tiene que mejorar la función A, entonces debe refactorizarla antes (¿y después?). Si no hace nada con esta función, déjela tal como está, siempre que tenga algo más que hacer.
No refactorice una parte activa del sistema, a menos que ya tenga que cambiarla.
Creo que esta entrada del blog Top 100 Wordpress puede tener algunos buenos consejos. http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/
Es como los parques nacionales: siempre déjalo un poco mejor de lo que lo encontraste.
Para mí, eso significa que cada vez que abro el código y tengo que rascarme la cabeza para descubrir qué está pasando, debería refacturar algo. Mi objetivo principal es la legibilidad y la comprensión. Normalmente se trata de cambiar el nombre de una variable para mayor claridad. A veces está extrayendo un método -
Por ejemplo (trivial), si me encontré
temp = array[i];
array[i] = array[j];
array[j] = temp;
Probablemente reemplazaría eso con un método de intercambio (i, j).
El compilador probablemente lo alineará de todos modos, y un intercambio () le dice a todos semánticamente lo que está sucediendo.
Dicho esto, con mi propio código (comenzando desde cero), tiendo a refactorizar para el diseño. A menudo me resulta más fácil trabajar en una clase concreta. Cuando esté listo y depurado, extraeré el viejo truco de la interfaz de extracción.
Dejaré que un compañero de trabajo lo refactorice para que sea legible, ya que estoy demasiado cerca del código para notar los agujeros. Después de todo, sé a qué me refería.
Escribes código con dos sombreros puestos. El gorro de trabajo justo y el sombrero de I-need-to-understand-this-tomorrow . Obviamente, el segundo sombrero es el de refactorización. Así que usted refactoriza cada vez que ha hecho que algo funcione, pero (inevitablemente) ha introducido olores como código duplicado, métodos largos, manejo de errores frágiles, nombres de variables incorrectos, etc.
Refactorizar al tratar de hacer que algo funcione (es decir, usar ambos sombreros) no es práctico para tareas no triviales. Pero posponer la refactorización hasta el siguiente día / semana / iteración es muy mala porque el contexto del problema desaparecerá de su cabeza. Así que cambie de sombreros con la mayor frecuencia posible, pero nunca los combine.
Hay muchos puntos de vista sobre este tema, algunos vinculados a una metodología o enfoque particular del desarrollo. Al utilizar TDD, refactorice temprano y, a menudo, es, como usted dice, un enfoque favorecido.
En otras situaciones, puede refactorizar como sea necesario. Por ejemplo, cuando detecta código repetitivo.
Al seguir métodos más tradicionales con un diseño frontal detallado, la refactorización puede ser menos frecuente. Sin embargo, recomendaría no dejar la refactorización hasta el final de un proyecto. No solo es probable que introduzca problemas, potencialmente posteriores a UAT, también es frecuente que la refactorización se vuelva progresivamente más difícil. Por este motivo, las restricciones de tiempo en el proyecto clásico provocan que se eliminen las tareas de refactorización y las pruebas adicionales, y cuando se inicia el mantenimiento, es posible que ya haya creado un monstruo con código de spaghetti.
Intento seguir este lema: dejar todo el código que tocas mejor de lo que era.
Cuando hago una corrección o agrego una función, generalmente uso esa oportunidad para hacer una refactorización limitada en el código afectado. A menudo, esto hace que sea más fácil hacer mi cambio previsto, por lo que en realidad no cuesta nada.
De lo contrario, debes presupuestar un tiempo dedicado para la refactorización, si no puedes porque siempre estás luchando contra incendios (me pregunto por qué) entonces deberías forzarte a refactorizar cuando descubres que hacer cambios es mucho más difícil de lo que debería y cuando el "código huele" son insoportables
La respuesta es siempre, pero más específicamente:
- Suponiendo que se ramifique para cada tarea, entonces en cada nueva rama, antes de que vaya a QA.
- Si desarrolla todo en el tronco, entonces antes de cada compromiso.
- Al mantener el código anterior, use lo anterior para las tareas nuevas, y para el código antiguo, refactorice en las versiones principales que obtendrán un control de calidad adicional.
Refactorizo cada vez que puedo porque me permite perfeccionar mi código lo mejor posible. Hago esto incluso cuando estoy desarrollando activamente para evitar la creación de código que no se puede mantener en primer lugar. También a menudo me permite enderezar una mala decisión de diseño antes de que se vuelva irreparable.
Si no está roto, no lo refactorice.
Yo diría que el momento de refactorizar pertenece a la etapa de codificación inicial, y puedes hacerlo con la frecuencia y tantas veces como quieras. Una vez que está en manos de un cliente, se convierte en una cuestión diferente. No quiere hacer el trabajo para usted mismo ''ordenando'' el código solo para descubrir que se envía y rompe algo.
El momento después de la entrega inicial al refactorizador es cuando dices que lo harás. Cuando el código se ponga un poco mal, entonces tenga una versión dedicada que contenga refactorizaciones y probablemente algunas correcciones más importantes. De esa manera, si rompes algo, sabes dónde salió mal, puedes arreglarlo con mucha más facilidad. Si se refactoriza todo el tiempo, romperá las cosas, no sabrá que está roto hasta que obtenga QAd, y entonces tendrá dificultades para tratar de averiguar si los cambios en el código de característica / función causaron el problema, o alguna refactorización que realizó hace años.
Verificar los cambios de crossover es mucho más fácil cuando el código se ve más o menos como solía hacerlo. Refactoriza una gran cantidad de estructura de código y puedes hacer que sea casi imposible, así que solo refactoriza cuando realmente quieras. Trátelo como lo haría con cualquier otro cambio de código de producto y debería estar bien.
Yo refactorio cuando:
Estoy modificando el código y estoy confundido por eso. Si me lleva un tiempo cribarlo, necesita una refactorización.
Estoy creando un nuevo código y después lo tengo "funcionando". Muchas veces voy a poner las cosas en marcha y mientras estoy codificando me doy cuenta "Oye, tengo que volver a hacer lo que hice 20 líneas, solo con unos pocos cambios". En ese punto, refactoré y continuaré.
Lo único que, en mi opinión, debería impedirte hacer esto es la falta de tiempo. Te guste o no, a veces simplemente no tienes tiempo para hacerlo.
"Refactorizar temprano, refactorizar a menudo" es una guía productiva. Aunque ese tipo de asume que realmente conoces el código. Cuanto más viejo se vuelve un sistema, más peligrosa se vuelve la refactorización, y se requiere más deliberación. En algunos casos, la refactorización debe ser tareas administradas, con estimaciones de nivel de esfuerzo y tiempo, etc.
Refactorizo cada vez que leo algo y puedo hacerlo más legible . No es una gran reestructuración. Pero si pienso "¿qué contiene esta List ? ¡Oh, Integer !" luego lo cambiaré a List<Integer> . Además, a menudo extraigo métodos en el IDE para poner un buen nombre de algunas líneas de código.
Estamos teniendo una discusión trabajando en esto ahora mismo. Estamos más o menos de acuerdo con que "lo escriba para que funcione y luego lo solucione". Pero diferimos en la perspectiva del tiempo. Soy más "corrige de inmediato", mi compañero de trabajo es más "corrige en la próxima iteración".
Algunas citas que lo respaldan:
Douglas Crockford, Arquitecto Principal de Javascript Yahoo:
refactor cada 7mo sprint.
Ken Thompson (hombre de Unix):
El código en sí mismo casi se pudre y se reescribirá. Incluso cuando nada ha cambiado, por alguna razón se pudre.
Me gustaría que una vez hecho con una tarea, el código enviado sea algo a lo que puedas volver en 2 meses y pensar "sí, lo hice bien aquí". No creo que sea fácil encontrar tiempo para volver más tarde y solucionarlo. creyendo que esto es algo ingenuo desde mi punto de vista.
Editar: error de ortografía
Si tiene una herramienta de refactorización que hará los cambios de manera segura, entonces deberá refactorizar cada vez que el código compile , si esto hará que el código sea más claro.
Si no tiene una herramienta de este tipo, debe refactorizar siempre que las pruebas sean de color verde , si esto hace que el código sea más claro.
Realice pequeños cambios: cambie el nombre de un método para que quede más claro. Extraiga una clase para hacer que un grupo de variables relacionadas esté claramente relacionado. Refactorizar no se trata de hacer grandes cambios, sino de hacer las cosas más limpias minuto a minuto. Refactorizar es limpiar sus platos después de cada comida, en lugar de esperar hasta que cada superficie esté cubierta de platos sucios.
Localizo la refactorización al código relacionado con mi tarea actual. Intento hacer mi refactorización desde el principio. Controlo estos cambios por separado ya que desde un punto de vista funcional, no está relacionado con la tarea real. De esta manera, el código es más limpio para trabajar y el historial de revisión también es más limpio.
Muchas veces, cuando estoy eliminando ideas, mi código comienza de forma muy estrecha y desordenada. A medida que empiezo a pulir la idea, las separaciones lógicas empiezan a volverse cada vez más claras y empiezo a refactorizar. Es un proceso constante y, como todos sugieren, debe hacerse "temprano y a menudo".
Refactor oportunista! Hazlo siempre que sea fácil .
Si la refacturación es difícil, entonces lo hace en el momento equivocado (cuando el código no lo necesita) o en la parte incorrecta del código (donde se obtienen mejores eficiencias en el lugar). (O aún no eres tan bueno para refactorizar).
Guardar la refactorización para "mantenimiento" es una tautología. La refactorización es mantenimiento.
Refactorizar a menudo puede salvar el día, o al menos un tiempo. Había un proyecto en el que estaba trabajando y refactorizamos todo nuestro código después de alcanzar un hito. Fue una gran manera porque si necesitábamos extraer el código que ya no era útil, facilitaba el parche en cualquier cosa nueva que necesitáramos.
Refactorizo el código tan pronto como sea funcional (todas las pruebas pasan). De esta manera, lo limpio cuando todavía está fresco en mi mente, y antes de que nadie más vea lo fea que era la primera versión.
Después del check-in inicial, normalmente me refactorio cada vez que toco una parte del código. La refacturación no es algo por lo que deba reservar un tiempo separado. Debería ser algo que acaba de hacer a medida que avanza.
Tres buenas razones para refactorizar:
- Tu diseño original (quizás en un área muy pequeña, pero de todos modos el diseño) fue incorrecto. Esto incluye dónde descubre una operación común y desea compartir el código.
- Usted está diseñando iterativamente.
- El código es tan malo que necesita una renovación importante.
Tres buenas razones para no refactorizar:
- "Esto se ve un poco desordenado".
- "No estoy del todo de acuerdo con la forma en que el último tipo hizo esto".
- "Puede ser más eficiente". (El problema es ''podría'').
"Desordenado" es controvertido: existe un argumento válido llamado "arreglar ventanas rotas", o "código de higiene", que sugiere que si dejas que las cosas pequeñas se deslicen, entonces comenzarás a dejar que las cosas grandes se deslicen también. Está bien, y es algo bueno a tener en cuenta, pero recuerda que es una analogía. No excusa el desordenar interminablemente, en busca de la solución más limpia posible.
La frecuencia con la que refactorice debe depender de la frecuencia con la que se producen las buenas razones y de la confianza que tiene en que el proceso de prueba lo proteja de la introducción de errores.
Refactorizar nunca es un objetivo en sí mismo. Pero si algo no funciona, tiene que ser corregido, y eso es tan cierto en el desarrollo inicial como en el mantenimiento. Para cambios no triviales, casi siempre es mejor refactorizar, e incorporar los nuevos conceptos limpiamente, que parchear un solo lugar con grandes cantidades de basura para evitar cualquier cambio en otro lugar.
Por lo que vale, no tengo inconveniente en cambiar una interfaz siempre que tenga una idea de lo que la usa y que el alcance del cambio resultante sea manejable.