Refactorizar o concentrarse en completar la aplicación

¿Refactorizaría su aplicación a medida que avanza o se centraría en completarla primero? Refactorizar significará que el progreso de la aplicación se ralentizará.

Completar la aplicación significará que obtendrás una aplicación posiblemente muy difícil de mantener más adelante.

La aplicación es un proyecto personal. Realmente no sé cómo responder "Qué impulsa la funcionalidad y el diseño", pero supongo que es para resolver las ineficiencias en el software actual. También me gusta el software mínimo fácil de usar. Así que estoy eliminando algunas funciones y agrego algunas que creo que ayudarán.

Hazlo funcionar. Entonces hazlo rápido. Finalmente, hazlo hermoso.

Si tiene una buena separación entre su código (presentación, negocio y capas de datos) utilizando interfaces, y no es un diseño monolítico, la refactorización no debería ser tan difícil.

Si tiene tantas dificultades para refactorizar, probablemente sea un olor a código: le sugiero que mire Principios sólidos

Creo que el punto esencial es mantener limpias las interfaces . Siempre puede refactorizar o incluso reescribir el módulo / clase / cualquier implementación posterior, siempre y cuando las capas de comunicación entre ellas sean sanas. Dedique un tiempo a descubrir qué es fácil de cambiar más adelante y qué no. Haga lo último bien.

Esto es consistente con el espíritu de TDD. Para escribir buenas pruebas, necesita una buena interfaz contra la cual probar. Lo desordenado que está detrás de escena en este momento no es tan importante, porque puedes mejorarlo más tarde.

Siempre refactorizo ​​a medida que avanzo, especialmente usando TDD.

1. Escribe las pruebas

2. Haz pasar las pruebas

3. Refactor

Esto lo ayudará a tener menos errores y un mejor código para el producto terminado. También le permitirá tener menos código para mantener cuando haya terminado.

Refactorizar temprano y con frecuencia! El tiempo que "ahorra" en no hacerlo se dedica muchas veces a intentar piratear la siguiente función y buscar errores en un código demasiado complejo o caótico.

Refactorizar es como recoger tu habitación.

Si mantiene las cosas ordenadas, tiene una sobrecarga lineal, proporcional a la cantidad de trabajo productivo que está haciendo en el código, O (n) en términos de algoritmos. Suponiendo que pasa el 10% de su tiempo refactorizando (o manteniendo su habitación ordenada), ese 10% es un hecho, y se mantendrá constante con el tiempo.

Sin embargo, si tira su ropa sucia en un rincón y continúa haciéndolo, la cantidad de tiempo que pasará recogiendo su habitación aumenta a medida que el desorden se vuelve más complejo. Suponiendo que cada pieza de ropa sucia individual contribuya exponencialmente al tiempo de limpieza requerido, ahora se encuentra en una situación O (e ⁿ ).

Cualquiera que haya profundizado en el concepto de complejidad algorítmica observará que hay un punto de equilibrio en alguna parte, es decir, que se acumula una cantidad óptima de ropa sucia; cuánto depende eso de los factores constantes que se descartan en la notación big-O. Otro factor es el valor de su trabajo a lo largo del tiempo: si su trabajo vale mucho ahora, pero es barato la próxima semana (es decir, hay un plazo este viernes para este proyecto y tres más, pero después de eso, estará inactivo en su mayoría ), la ecuación podría resultar a favor de no refactorizar.

Y luego está la complejidad de la masa crítica. En algún momento, el desorden ('desorden crítico', si lo desea) se vuelve tan malo que parece más fácil quemar toda la habitación y comprar ropa nueva. En realidad, generalmente no lo es, pero parece de esa manera, y los efectos psicológicos harán que sea diez veces más difícil abordar la cuestión.

Y obviamente, si entras en un proyecto que ya es un desastre gigante de redundancia múltiple, tienes opciones limitadas.

TL; DR: En caso de duda, refactorizar. Debería tener pruebas realmente buenas antes de decidir no hacerlo.

Si tiene la oportunidad de agregar funciones o eliminar errores para obtener su satisfacción de ventas / cliente donde cree que debería estar, hágalo. Una vez que haya menos demandas nuevas, puede equilibrarlas con la refactorización. En algún momento, debes asegurarte de escribir el código que la gente quiere. En igualdad de condiciones, prefiero tirar 100 horas de código en lugar de 1000. Que es lo que harás si nadie lo quiere.

Realmente depende de dónde estás!

Otras cosas para pensar:

¿Qué tan seguro está, realmente tiene el diseño funcional correcto? ¿Podría terminar rediseñando nuevamente después de recibir comentarios de los usuarios?

Prefiero liberar que reescribir. Optimice después de estar seguro de haber clavado el diseño funcional.

Mientras esté seguro de que puede cumplir con la fecha límite, puede refactorizar todo lo que quiera. Sin embargo, incluso si hay un poco de incertidumbre mejor para seguir con el desarrollo y puede ser refactorizado solo en un paso incremental modesto.

Si el mal diseño que desea refactorizar realmente le duele, será mejor que lo arregle ahora que crear más código que dependa de él. Refactorizar más tarde sería más difícil y más costoso; lo más probable es que ya no puedas hacerlo.

Por otro lado, si su único problema es la fealdad, es posible que desee completar su software primero, porque casi nada supera hacer las cosas .

La refactorización será muy importante a medida que trabaje para completar su solicitud.

+ VES

1. Flujo claro: la refactorización dará claridad al código porque a veces, si el código está poco desestructurado, comprenda el flujo del código después de un período de tiempo que se volverá difícil y la refactorización del código podría convertirse en una tarea cuesta arriba y podrían introducirse errores.

2. Mejore el rendimiento: la refactorización adecuada de la aplicación definitivamente ayudará a mejorar el rendimiento de la aplicación.

3. Mantenimiento: por último, pero no menos importante, sería más fácil de mantener a largo plazo.

-VE

1. Consumo de tiempo: sería mucho más tiempo en cada etapa de su progreso. Entonces podría haber una demora en completarse

Línea de fondo

Dependiendo del tipo de proyecto, puede priorizar la calidad del código o la finalización, lo que sea más exigente para la situación actual.

Basado en mi experiencia personal, generalmente iría a terminar las aplicaciones primero con la condición de que haya una fecha límite para alcanzar. una vez que lo haya completado, puede refactorizarlo.

Terminarlo y refactorizarlo. Pero si no hay una fecha límite para ser apresurado o un marco de tiempo, sugiero refactorizarlo sería bueno.