refactoring - software - ¿Refactorización prematura?
refactorizar js (8)
Todos hemos oído hablar de la optimización prematura, pero ¿qué piensas sobre la refactorización prematura? ¿Hay algo así en tu opinión?
Sí hay. La refactorización es una forma de pagar la deuda técnica que se ha acumulado a lo largo de la vida de su proceso de desarrollo. Sin embargo, la mera acumulación de deuda técnica no es necesariamente algo malo.
Para ver por qué, imagine que está escribiendo un software de análisis de devolución de impuestos para el IRS. De repente, se introducen nuevas regulaciones en el último minuto que rompen varias de sus suposiciones originales. Aunque usted diseñó bien, su modelo de dominio ha cambiado fundamentalmente desde debajo de sus pies en al menos un lugar importante. Es el 14 de abril, y el proyecto debe comenzar mañana, venga el infierno o marea alta. ¿Qué haces?
- Si implementa una solución de tuercas y tornillos a costa de una deuda técnica moderada, su sistema se volverá más rígido y será menos capaz de soportar otra ronda de estos cambios. Pero el sitio puede comenzar a funcionar y seguir adelante, y no habrá riesgo de entrega tardía; Usted está seguro de que puede hacer los cambios necesarios.
- Por otro lado, si se toma el tiempo de refactorizar la solución para que ahora admita el nuevo diseño de una manera más sofisticada y flexible, no tendrá problemas para adaptarse a los cambios futuros. Pero corres el riesgo de que el producto estrella de tu empresa se oponga al reloj; no está seguro si el rediseño tomará más tiempo que hoy.
En este caso, la primera opción es la mejor opción. Suponiendo que tenga poca deuda técnica anterior, vale la pena tomar sus bultos ahora y pagarlos más tarde. Esto es, por supuesto, una decisión de negocios, y no una decisión de diseño.
Todos hemos oído hablar de optimización prematura , pero ¿qué piensas acerca de la refactorización prematura? ¿Hay algo así en tu opinión? Aquí es a lo que estoy llegando.
En primer lugar, la lectura del trabajo seminal de Martin Fowler, "Refactoring" cambió literalmente mi vida con respecto a la programación.
Sin embargo, una cosa que he notado es que si comienzo a refactorizar una clase o un marco demasiado rápido, a veces me encuentro codificado en una esquina, por así decirlo. Ahora, sospecho que el problema no es realmente refactorización en sí, sino quizás decisiones / suposiciones de diseño prematuras / deficientes.
¿Cuáles son sus pensamientos, ideas y / u opiniones sobre este tema? ¿Tiene algún consejo o anti-patrones comunes relacionados con este problema?
EDITAR:
Después de leer sus respuestas y reflexionar más sobre este tema, creo que me he dado cuenta de que mi problema en este caso es realmente un problema de "diseño prematuro" y no necesariamente de "refactorización prematura". He sido culpable de asumir un diseño y refactorización en esa dirección al inicio del proceso de codificación. Un poco de paciencia de mi parte para mantener un nivel de agnosticismo en el diseño y centrarme en la refactorización hacia un código limpio me impediría descender por estos senderos de diseño de conejos.
Creo que cualquier proyecto "1.0" es susceptible a este tipo de ... llamémoslo "diseño iterativo". Si no tiene una especificación clara antes de comenzar a diseñar sus objetos, es probable que piense en muchos diseños y enfoques de los problemas.
Por lo tanto, creo que superar este problema específico es diseñar cosas claramente antes de comenzar a escribir código.
Creo que es posible refactorizar demasiado pronto.
En el extremo de diseño de las tuercas y tornillos está el código en sí. Esta etapa final del diseño comienza a existir a medida que usted codifica, a veces tendrá fallas, y verá que a medida que el código evoluciona. Si refactoriza demasiado pronto, es más difícil cambiar el diseño defectuoso.
Por ejemplo, es mucho más fácil eliminar una sola función larga cuando te das cuenta de que es basura o va en la dirección equivocada que eliminar una buena función bien formada y las funciones que utiliza y las funciones que utilizan, etc. No estás rompiendo algo más que era parte del refactor.
Se podría decir que tal vez debería haber dedicado más tiempo al diseño, pero un elemento clave en un proceso ágil es que la codificación es parte del proceso de diseño y, en la mayoría de los casos, al poner un esfuerzo razonable en el diseño, es mejor simplemente seguir adelante. con eso.
Editar En respuesta a los comentarios: -
El diseño no se hace hasta que hayas escrito el código. No podemos resolver todos los problemas en el diseño de codificación previa, el punto detrás de Agile es que la codificación es la resolución de problemas. Si el diseño sin código resolviera todos los problemas por adelantado antes de la codificación, no habría necesidad de tener en cuenta el factor, simplemente convertiríamos el diseño en código bien factorizado en un solo paso.
¿Alguien recuerda los métodos de diseño estructurado de finales de los 80 y principios de los 90, en los que resolvió todos los problemas en diagramas inteligentes antes de escribir una línea de código?
En realidad pienso lo contrario.
Cuanto antes comience a pensar si su diseño necesita refactorización o no, mejor. Refactorizar constantemente, por lo que nunca es un gran problema.
También descubrí que cuanto más refactorizaba desde el principio, mejor me había puesto a la hora de escribir el código de manera más limpia al principio. Tiendo a crear menos métodos grandes, y tengo menos problemas.
Sin embargo, si se encuentra "refactorizándose" en una esquina, me parece que es más una cuestión de falta de diseño inicial o de planificación para el alcance de uso de una clase. Intente escribir cómo desea usar la clase o el marco antes de comenzar a escribir el código; puede ayudarlo a evitar ese problema. Creo que esta es una de las ventajas de probar el diseño impulsado: te ayuda a obligarte a utilizar el objeto antes de que se escriba.
Recuerde, la refactorización técnicamente NUNCA debe encerrarlo en una esquina: se trata de volver a trabajar los elementos internos sin cambiar la forma en que se utiliza una clase. Si te estás atrapando refactorizando, significa que tu diseño inicial fue defectuoso.
Lo más probable es que, con el tiempo, este problema mejore y mejore. Su diseño de clase y marco probablemente terminará más flexible.
Hay un par de soluciones prometedoras para este tipo de problema, dependiendo de la situación.
Si el problema es que usted decide que algo puede optimizarse de cierta manera y extrae un método o algo y se da cuenta de que, debido a esa decisión, se ve obligado a codificar todo lo demás de una manera complicada, probablemente el problema sea que no lo hizo. Piensa lo suficiente en el proceso de diseño. Si hubiera habido una especificación bien escrita y planificada, habrías sabido de este problema con anticipación (a menos que no hayas leído la especificación, pero ese es otro problema :))
Dependiendo de la situación, la creación rápida de prototipos también puede solucionar este problema, ya que tendrá una mejor idea de estos detalles de implementación cuando comience a trabajar en la realidad.
La razón por la que la optimización prematura es mala es que la optimización generalmente conduce a un diseño peor. A diferencia de la refactorización, lo que conduce a un diseño mejor y más limpio, si se realiza de manera inteligente y correcta. Lo que aprendí a ser útil para analizar la utilidad de una refactorización fue mirar primero nuestro diagrama UML para visualizar el cambio y luego escribir el código-doc (por ejemplo, Javadoc) para la clase primero y agregar talones antes de cualquier código real. Por supuesto, la experiencia ayuda mucho con eso, si tiene dudas, consulte a su arquitecto favorito;)
Soy un fuerte creyente en la refactorización constante. No hay razón para esperar hasta un tiempo específico para comenzar la refactorización.
Cada vez que veas algo que debería hacerse mejor, Refactor.
Sólo mantén esto en mi mente. Conozco a un desarrollador (un genio puro) que se refacciona tanto (es tan inteligente que siempre puede encontrar una mejor manera) que nunca termina un proyecto.
La refactorización prematura es la refactorización sin pruebas unitarias. Usted está en ese punto, simplemente no está listo para una refactorización. Primero obtenga algunas pruebas unitarias y luego comience a pensar en la refactorización. De lo contrario, podría dañar el proyecto más que ayudar.