Una gran parte de mi código tiene un defecto de diseño importante. ¿Terminarlo o arreglarlo ahora? [cerrado]

Si estuviera en tus zapatos, probablemente lo intentaría de esta manera:

• primero, finalice el proyecto actual, al menos parcialmente, lo antes posible, pero en un estado de trabajo . Probablemente necesite reducir sus objetivos originales, piense en la funcionalidad mínima que realmente necesita ver en la "versión 1.0".

• entonces, y solo entonces piense en una reescritura desde cero (llamémosla "versión 2.0"). Quizás pueda reutilizar parte del código de V1.0. Tal vez después de volver a dormir sobre la situación, tome la decisión de refactorizar V1.0 y guardar la mayor parte. Pero no tome esta decisión antes de no tener a mano una "prueba de concepto V1.0".

Un programa de trabajo "1.0" es algo que puede mostrar a otros, incluso cuando el código es malo (que nadie más se molestará, excepto usted mismo). Si en medio de crear V2.0 te das cuenta de que te estás quedando sin tiempo, todavía tienes V1.0 como un éxito parcial, lo que será mucho mejor para tu moral. Sin embargo, si no finaliza V1.0 primero, existe una gran posibilidad de que nunca complete V2.0 porque cuando esté a mitad de camino, habrá un punto en el que no esté satisfecho con el diseño nuevamente, y luego? ¿Volverás a abandonar V2.0 y trabajarás en V3.0? Existe un alto riesgo de toparse con este círculo sin fin, de no llegar a su fin.

Es mejor que tome esto como una oportunidad para aprender cómo alcanzar metas intermedias, en lugar de una oportunidad para aprender cómo dejar proyectos en un estado sin terminar.

Los proyectos de TI terminados, incluso los defectuosos, son mucho mejores que los no terminados.

Los no terminados también pueden enseñarte mucho, pero no tanto como los terminados.

Puede que no lo veas ahora, pero obtienes una enorme cantidad de valor trabajando incluso con código defectuoso.

Mi voto es para terminar y luego, quizás, refactorizar, si es necesario. Cuando empieces a trabajar con más proyectos, verás que, sorprendentemente, la parte que "estaba destinada a ser refaccionada" permanece intacta durante años, mientras que otras piezas se extienden.

Desde el punto de vista de empleo, en la mayoría de los casos, obtendrá más felicitaciones por un proyecto terminado.

Me encantaría volver a empezar el proyecto.

Eres un estudiante, y todavía estás aprendiendo. Esto te coloca en una posición muy diferente a la pregunta a la que te vinculaste.

• Usted no tiene responsabilidad profesional por su código; Si tuviera que eliminar todo el proyecto en este momento y se fuera, no sufriría ninguna repercusión. Esta es una gran ventaja para un desarrollador. En la pregunta que vinculaste, esos desarrolladores intentan mantener el software por el que la gente está pagando, e incluso pequeños errores pueden causar grandes problemas con los clientes, lo que hace que sea peligroso escribir desde cero. No tienes ese problema.

• Como proyecto personal, esta es la oportunidad perfecta para probar cosas nuevas y aprender de sus errores. Es genial que reconozcas que tu código anterior tiene problemas, porque eso significa que has aprendido cómo hacerlo mejor. La experiencia a través de prueba y error puede ser invaluable para los programadores principiantes.

• Su proyecto es relativamente pequeño y básicamente no tiene pruebas. Podría ser tan breve como unas pocas noches escribir 3000 líneas desde cero, especialmente porque ya tiene ideas sobre qué hacer mejor la próxima vez.

• Trabajar en una base de código dañada supondrá un gasto mucho mayor para tu moral que una reescritura.

Como nota aparte, esta puede ser una gran oportunidad para intentar escribir un programa más modular con pruebas unitarias. Si lo hace, le resultará mucho más fácil entender el código si vuelve a usarlo después de un largo descanso, y ayuda a evitar errores que pueda introducir accidentalmente debido a un olvido.

Finalmente, aquí es una opinión sobre la conveniencia de dar pasos hacia atrás para dar pasos más grandes hacia adelante.

Probablemente todavía estés en la parte de "aprendizaje rápido" de tu desarrollo. Hay una buena posibilidad de que dentro de unos meses, descubras que tu nuevo e impresionante diseño está horriblemente roto de una forma que ni siquiera sabías cuando empezaste.

Haga las cosas : esta es la cosa más importante que necesita aprender. Créeme, conozco a muchas personas (no solo programadores) que están atascadas en el ciclo de "volver a empezar desde cero, ya que he aprendido mucho antes de comenzar con este proyecto". El problema es que nunca termina , hasta que dejas de aprender cosas nuevas, lo que no es un buen lugar para estar :)

También es importante para poder realmente terminar cualquier cosa. Comenzar de nuevo es emocionante, genial, divertido ... pero si solo aprendes eso, nunca podrás terminar nada. Una vez más, esa no es una habilidad muy útil, y en realidad no se siente tan bien como hacer algo útil (o divertido). La vida es corta, el tiempo es limitado y no puedes seguir practicando sin resultados tangibles; te volverás loco por eso. Si no puede comenzar a trabajar porque simplemente no puede decidir qué enfoque tomar, ya está en la zona de peligro.

Siempre habrá impulsos para comenzar de nuevo. Incluso en un entorno de aprendizaje, lo más probable es que sea una mala idea. Eso no significa que tenga que llevar cada prototipo a una aplicación lista para producción, ni mucho menos. Pero necesita al menos llegar a una fase de prototipo en funcionamiento; lo más probable es que ayude a su moral, y es un rasgo muy útil para un desarrollador de cualquier tipo. Haz las cosas . Y la parte divertida es que verás rápidamente que hay un millón de cosas más divertidas o útiles que puedes hacer con tu prototipo en lugar de "reescribirlo desde cero", y en muchos casos, incluso refactorizarlo. Todo lo que haces tiene un costo, al menos, podrías haber estado haciendo otra cosa mientras tanto.

Sigo la "Haz que funcione, hazlo bien, hazlo rápido" en el desarrollo de software.

1. Haz que funcione : escribe la funcionalidad principal, para que el proyecto sea utilizable. Haz lo que tienes que hacer para que todo funcione, incluso si significa un código feo.
2. Hazlo bien : corrige errores y refactoriza el código para que sea más fácil de leer, entender y mantener.
3. Hágalo rápido : optimice el programa, buscando un buen equilibrio entre la velocidad, el uso de recursos y la capacidad de mantenimiento.

En este momento, no has terminado el paso 1. Haz que funcione primero, y luego puedes preocuparte por lo feo que es tu código. En realidad, crear un producto que funcione es una de las cosas más difíciles para los nuevos desarrolladores, ya que están tan envueltos en tratar de hacer que su código sea perfecto la primera vez, y por eso se quedan atascados en Optimization Hell y nunca llegan a terminar. Implementando todas las características. Tienes que aprender a dejar de lado todas esas preocupaciones sobre refactorización y optimización para que puedas concentrarte en hacer que el software funcione. Una vez que obtenga algo más de experiencia, naturalmente hará más cosas bien la primera vez, por lo que será necesario menos refactorización.

Recuerde: la optimización prematura es la raíz de todo mal (consulte esta excelente pregunta de Programmers.SE para una buena discusión). Si pasa demasiado tiempo pensando en cómo mejorar su código, se queda atascado en análisis de parálisis . Esto mata el proyecto. Es mejor terminar el proyecto antes de intentar optimizarlo.

Para citar a un gran orador motivacional: simplemente hazlo .

Como siempre, hay un xkcd relevante:

Vuelve a escribirlo. El código que no funciona tiene poco valor y tres mil líneas no es mucho código. No tardará tanto tiempo en escribir el código que tiene actualmente, y será mucho mejor. A menudo he tirado quinientas o mil líneas de código deficiente y, a menudo, la reescritura es una quinta parte.

La mayoría de las nociones en torno a "no reescribir" se relacionan con los sistemas grandes que hacen cosas importantes y que se someten a cambios constantes para cumplir con los requisitos en evolución. Las reescrituras de sistemas complejos en uso rara vez tienen éxito.

Tu situación es todo lo contrario. Tiene una aplicación pequeña sin usuarios y los únicos requisitos son los que elige implementar. Así que sigue adelante y reescríbelo.

El reinicio desde cero suele ser un mal movimiento en los proyectos de la vida real, principalmente porque los proyectos de la vida real acumulan correcciones de errores que un desarrollador nuevo no conoce (por ejemplo, consulte Cosas que nunca debes hacer , de Joel on Software blog.)

No obstante, los proyectos escolares no heredan dicha historia y, por lo general, comienzan por codificar y diseñar al mismo tiempo con un conocimiento parcial de la informática y la falta de experiencia. Consideraría su primera versión como un prototipo, usado como una prueba de concepto que ha fallado, y felizmente lo tiraría (vea ¿Cuáles son las diferencias entre los prototipos desechables y los evolutivos? para una discusión acerca de los prototipos desechables y evolutivos.)

El diseño correcto ha madurado en tu cabeza y no debería tomar mucho tiempo para escribirlo en el código.

Respetuosamente, no estoy de acuerdo con las sugerencias de que volver a escribir es una mala idea.

En el ámbito del ciclo de vida del software, generalmente se acepta que el tiempo y el esfuerzo necesarios para corregir un error aumentan en un orden de magnitud en cada capa del ciclo de vida. Es decir, si toma 1 hora corregir un error en el nivel de requisitos, tomará 10 horas en diseño, 100 horas en pruebas de codificación y 1000 horas como solución de errores. Esos números pueden sonar extravagantes, pero son aceptados por la industria como aproximadamente correctos. Obviamente, menos en un proyecto más pequeño, pero la idea general permanece. Si su proyecto tiene un defecto de diseño básico, es más apropiado llamar a eso una experiencia de aprendizaje y regresar, revisar sus requisitos iniciales y rediseñar.

También recomendaría considerar un modelo de desarrollo guiado por pruebas utilizando pruebas unitarias estructuradas. Son un dolor y, inicialmente, parecen una pérdida de tiempo, pero su capacidad para descubrir errores, especialmente cuando se integran con el código de otra persona, no se puede dejar de mencionar.

Me perdiste en esta frase:

  

El problema es que no he terminado ni siquiera la funcionalidad principal de mi programa, por lo que no puedo realmente refactorizarlo, y me siento desanimado a seguir perfectamente consciente de que el diseño de mi código es defectuoso.

Creo en el principio (establecido en Systemantics ) que

  

• Se encuentra invariablemente que un sistema complejo que funciona ha evolucionado a partir de un sistema simple que funciona.
  
• Un sistema complejo diseñado desde cero nunca funciona y no se puede reparar para que funcione. Debe comenzar de nuevo, comenzando con un sistema simple que funcione.
  

Por lo tanto, escribir un sistema complejo incluye

• escribiendo un sistema simple
• Asegurarse de que funcione

... es decir, los siguientes pasos:

1. Escribe un poco de código
2. Pruébelo para asegurarse de que funcione
3. escribe un poco más de código
4. Prueba de nuevo
5. Etc.

Tenga en cuenta que el paso 3 podría incluir:

3. escribe un poco más de código
   1. Refactoriza el código existente para prepararlo para una nueva adición
   2. Pruebe la refactorización para asegurarse de que aún funciona
   3. Agregar la nueva funcionalidad

Además, el Paso 2 "Pruébalo para asegurarte de que funciona" podría implicar una reescritura si no lo hace.

Si estuviera construyendo sobre una base de código podrida, no estaría dispuesto a agregar más funciones. Así que me inclino a programar algo como "simplificar la implementación de subprocesos existentes" como la próxima pieza de trabajo a implementar. Suponiendo que ha estado realizando pruebas a medida que avanza, debería poder tratar esto como un ejercicio de refactorización. Los criterios de éxito / salida para esta fase de trabajo serían:

• El código fuente es más simple
• Y no se han introducido nuevos errores
• (Y algunos errores viejos eliminados)

Por cierto, "probarlo para asegurarse de que funciona" no significa necesariamente "pruebas unitarias"; cuando la estructura del equipo es simple, puede probar un sistema (simple) utilizando (simple) pruebas del sistema (en lugar de pruebas unitarias) .

Uno de los problemas a los que te enfrentas cuando te encuentras con un problema como este, es que estás conectado emocionalmente con el código que has escrito hasta el momento de alguna manera u otra.

Un colega me dijo que estaba escribiendo un programa mientras estaba en la universidad mientras recibía lecciones de un profesor famoso (creo que era Dijkstra). Le pidió al profesor que examinara el código en el que había estado trabajando durante más de un mes. El profesor le preguntó si había hecho una copia de seguridad, él respondió que no. El profesor luego eliminó todo su código y le dijo que lo escribiera de nuevo.

Estaba enojado, pero 3 días después terminó el programa, con un código más limpio y menos errores y menos líneas de código.

Intente hacer una estimación honesta sobre qué opción es la mejor en el tiempo disponible para el proyecto.

Las 3 opciones son

• Bórralo (completamente, sin mirar atrás)
• Continuar trabajando en el diseño antiguo
• Código de refactor mientras vas.

He sido programador profesional durante más de 10 años, y en mi línea de trabajo llegué a la conclusión de que la última opción es la mayoría de las veces la elegida, pero no siempre es la mejor opción.

Parece que tus habilidades han crecido sustancialmente en ese período de tiempo. Quizás trabajar en ese proyecto contribuyó a ello. Diseñarlo de nuevo como una experiencia de aprendizaje intencional sería fructífero.

Recuerde, esto no es algo que deba entregar como un programa de trabajo para un cliente. Fue escrito específicamente para la práctica. Entonces, a menos que desee practicar problemas de envío y entrega defectuosa, creo que actualmente se encuentra en una fase de desarrollo en la que trabajar sus "músculos de diseño" sería fructífero.

Al hacerlo, enfócate en el proceso de diseño y planificación, reflexiona sobre tus cosas existentes y reflexiona sobre lo que estás entendiendo mejor.

Refactor. Refactor Refactor REFACTOR !!!!

Honestamente, no importa cuánta experiencia tengas, este es un problema común. Usted escribió el código, aprendió algo y desea utilizar el nuevo conocimiento en el código anterior. Quiere medir el código antiguo con el nuevo conocimiento.

Eso simplemente no funcionará. Si haces eso tu aplicación / juego nunca se completará. En su lugar, intente asignar su tiempo en el proyecto para que algunas de sus "tareas" sean refactorizar el código incorrecto. Digamos, por ejemplo, que tenías un horrible método para salvar el juego. Sigue trabajando en el juego en sí, pero encuentra tiempo para refactorizar (reemplazar) ese horrible método. Trate de mantener los refactores pequeños, y no debería ser un problema.

Cuando llegas a la mayor parte de la aplicación que necesita un refactor, lo estás haciendo mal, en serio. Rompe esa refactorización en partes más pequeñas. Trate de pasar siete horas escribiendo el código y refactorizando una hora.

Cuando hayas terminado con el proyecto y hayas bloqueado la función, puedes dedicar un tiempo masivo a refactorizar. Por ahora, termina el juego, pero aún así intenta refactorizarlo. Eso es lo mejor que puedes hacer.

Siempre habrá algo para refactorizar.

Yo diría que depende un poco de qué tipo de código tiene ahora y dónde están los problemas exactamente. Es decir, si sus cimientos son buenos (diseño de clase apropiado en la mayoría de las partes, buen desacoplamiento / cohesión, etc., solo algunas elecciones malas como los hilos que mencionó), entonces, por supuesto, obtenga una versión 1.0 y refactorice como no hay mañana.

Por otro lado, si en realidad es solo un montón de archivos de texto feos y borrachos que de alguna manera pasan al compilador, sin una estructura discernible, etc. (en otras palabras, una prueba de concepto de aprendizaje en el trabajo prototipo), entonces prefiero borrarlo y volver a empezar.

En su próxima versión, haga un enfoque ágil: establezca una línea de tiempo de repetición fija, como 2 semanas o lo que sea que se ajuste a su horario. Al comienzo de cada fragmento (llamémoslo un sprint), establezca metas que se puedan alcanzar en las 2 semanas. Sigue adelante y hazlos, haz todo lo posible para que funcione. Establezca sus metas para que después de cada 2 semanas tenga algo que pueda mostrarle a un amigo, no solo un trabajo interno abstracto. Google "scrum" y "gol inteligente". Todo esto es muy fácil de hacer, si estás solo, solo un pedazo de papel con unas pocas viñetas anotadas rápidamente.

Si puedes hacer eso, entonces empezar de nuevo es bueno. Si sabes muy bien que, después de volver a empezar, es probable que termines donde estás ahora, de todos modos, mantén tu código y haz que funcione.

Tienes que ponerte en los zapatos de los empleadores.

Para la mayoría de los reclutadores, serías el más valioso si siguieras este camino: - Termine con el 100% de las pruebas en el nuevo código que escribe. - Añadir pruebas para el código antiguo (mal diseñado). - Refactorícelo para lograr lo que quería como diseño.

Haga todo eso con un buen proceso de versionado, ramas y etiquetas.

La reescritura es a menudo una idea atractiva, pero a menudo es una idea que tienen los recién llegados, lo cual es algo peligroso en la vida real. Mostrar que estás más dispuesto a mejorar la calidad del trabajo que ya hiciste en lugar de comenzar desde cero es una buena señal de que eres una persona seria.

Es obvio que puedes reescribirlo, pero hazlo como otro proyecto.

Solo para agregar algo de mi experiencia pasada en la mezcla. He estado trabajando en un proyecto paralelo durante más de un año, cada vez que tengo unos minutos de repuesto. Este proyecto pasó de un simple banco de pruebas a una clase estática a un diseño de líneas finas orientado a objetos que es ahora.

A lo largo de todos estos cambios, he mantenido la misma funcionalidad del código, excluyendo las correcciones de errores y los beneficios de rendimiento (debe ser lo más rápido posible). El mismo código base, aunque refactorizado, se ha mantenido igual y, como tal, lo he mejorado enormemente sin tener que volver a escribir el código desde cero y perder el tiempo.

Esto ha significado que he podido mejorar el código a un ritmo más rápido de lo que hubiera podido antes. También significaba que, a medida que iba, era más fácil decir lo que debía eliminarse, es decir, las clases innecesarias, y lo que podría ser más fácil que volver a escribir con la vieja idea aún en mi mente.

Por lo tanto, mi consejo sería refactorizar su código y continuar desde allí haciendo las mejoras necesarias. Aunque recuerde que si decide reescribir desde cero, debe tomar las buenas ideas del proyecto anterior y mirarlas detenidamente para ver dónde están defectuosas. Es decir. no solo copie el código antiguo al nuevo proyecto.

La respuesta depende de algo que me gusta llamar "límite de complejidad". A medida que agrega más y más a una base de código, hay una tendencia a que se vuelva cada vez más complejo y menos organizado. En algún momento, alcanzará un "límite de complejidad", momento en el que el progreso será muy difícil. En lugar de tratar de seguir moviéndose por la fuerza bruta, es mejor hacer una copia de seguridad, reorganizar / reescribir y luego continuar avanzando.

¿Entonces su base de código es tan mala que se está acercando a un techo de complejidad? Si siente que lo es, tómese un tiempo para limpiar y simplificar antes de continuar. Si la forma más fácil de limpiar es reescribir algunas partes, está bien.

¿Ninguno? ¿Ambos?

Continuar, pasar un tiempo revisando el diseño existente y agregar una nueva funcionalidad.

Si tiene interacciones rápidas, ese podría ser un buen lugar para comenzar (los "subprocesos excesivos en el renderizador" suenan como una ineficiencia, en lugar de algo que podría causar problemas de corrección). Vea si puede descubrir una forma general de alejarse de las carreras (y posiblemente puntos muertos), o al menos varias formas específicas de hacerlo.

No sé en qué medida están disponibles los detectores de interbloqueo y de carrera para C #, pero si existen, pueden ser útiles para identificar los problemas que existen y verificar que las correcciones funcionan.

Encuentro que, en general, estoy más motivado para solucionar problemas con el código que hace algo útil, en lugar de tirarlo y comenzar, nuevamente, desde cero. Hay casos en los que el desarrollo del campo chamuscado (en analogía con greenfield y brownfield ...) es más satisfactorio, pero generalmente es para cosas en las que el enfoque existente está tan alejado de donde debería ser que ya ni siquiera es incorrecto. / p>     

Si su código es modular, debería poder terminar el resto del código alrededor de los componentes mal escritos y luego reescribir los componentes mal escritos sin afectar el resto del código.

En ese caso, depende de usted cuando vuelva a escribir los componentes mal escritos. Si los componentes mal escritos están tan mal escritos que el código finalizado no funcionará con ellos como están, entonces deberá volver a escribirlos antes de que pueda terminar el resto del código.

La primera pregunta que debe hacerse es "¿qué tan grave es la falla?"

¿Qué es exactamente lo que hiciste mal?

Si algo es tan malo que perderá un montón de horas tratando de resolver el problema, expone datos confidenciales (contraseñas / tarjetas de crédito) o provoca una vulnerabilidad grave, tal vez debería editarlo, pero la mayoría de los tiempo que puede tomar lo que tiene, terminarlo y solucionar el problema más adelante.

A los programadores les encanta mejorar sus aplicaciones, queriendo que sean "lo mejor que puede ser", pero ese no es el enfoque correcto.

Si liberas tu aplicación lo antes posible, incluso si no es del 100%, todos los errores se superan, entonces obtienes FEEDBACK de otros, mientras tienes tiempo para corregir los errores y otras cosas para la versión 1.1. Otras personas podrán ayudarte a mejorar mucho la aplicación, y es posible que tengas tiempo perdido haciendo algo que a la gente no le gustó.

Entonces, en su caso, expréselo, obtenga algunos comentarios, y luego puede estructurar la versión 2.0 con todos los cambios, y corregir la falla que tiene.

Otra cosa para recordar es que estamos mejorando constantemente. Hay un dicho que dice que si puedes ver tu código de hace un año y ver que es malo, eso significa que sigues mejorando y eso es una gran cosa.

Depende de cuán desordenado esté tu código.

• Si cometió errores reales n00b que hacen que su código sea demasiado complejo o detallado, le recomiendo que vuelva a escribir esas partes.

• Si cree que tiene errores graves que tendrá que corregir de todos modos, escriba algunas pruebas unitarias que puedan verificar si ha solucionado el error (... ya que aún no puede iniciar el programa ). Es mejor corregir los errores antes de tiempo, y definitivamente es mejor corregirlos mientras aún recuerdas lo que hace el código.

• Si no te gusta cómo se llaman los métodos, a qué clase pertenecen, o cosas pequeñas como esa, entonces solo usa el IDE. (Recuerde, esto es C #, no algunos javascript, python, perl, php, etc.) Cuando está trabajando en el código que utiliza el componente afectado, y tiene una idea clara de lo que debería hacer ese componente, luego refáctelo si su IDE lo hace indoloro.

De lo contrario, haz que funcione y perfecciona tus habilidades en el próximo proyecto.

Como han sugerido otros, ya que este es un proyecto personal, no (aún) un proyecto profesional, consideraría seriamente una reescritura.

Sin embargo, puede aprovechar el método científico aquí, realizando un experimento. En primer lugar, concebir una hipótesis. El mío sería: "probablemente sea el momento de una reescritura". Para ahorrar tiempo, reduzca el costo de la falla y, de alguna manera, limite el sesgo a priori, antes de continuar con la programación, decida un período de tiempo ("casilla de tiempo"). Sugeriría quizás 4 horas de pared. Decidir también una metodología para evaluar la hipótesis. Dado que las apuestas son bajas, sugeriría como metodología, simplemente pregúntese: "¿me alegro de haberlo hecho?" Ahora comienza el experimento. Después de la casilla de tiempo elegida, ¿cuál es la evaluación de la hipótesis? p.ej. En mi ejemplo, ¿te alegra haber comenzado a reescribir ahora que has pasado 4 horas haciéndolo? Entonces probablemente sea la elección correcta.

Puedes pedir todos los consejos del mundo, pero no hay nada como probar una hipótesis empíricamente.

Algunas razones para considerar la selección de una reescritura como su experimento:

• En mi experiencia, generalmente es más divertido. Una razón importante por la que las reescrituras no se seleccionan en situaciones profesionales es que la diversión está lejos del criterio exclusivo. Pero todavía eres relativamente nuevo en la codificación, por lo que la diversión es probablemente un criterio muy importante, y también un indicador de otros factores que pueden ser intangibles para ti en esta etapa temprana (la diversión sugiere que aprenderás más, etc.).
• Tu experiencia y, probablemente, un sentido de conciencia molesto parecen decirte que vale la pena considerar una reescritura. Escucha esa voz, si la hay. Incluso si no sigues su consejo, al menos escucha. En el futuro habrá más voces externas, y usted necesita practicar la audición de su propio sentido común.
• Sospecho que con una reescritura, es más probable que modules tu código más. Cuando crea módulos, tiene componentes más reutilizables y confiables que puede aprovechar para otros proyectos. Incluso puede encontrar que al final, lo que parecía un mero módulo de su proyecto principal resulta ser la pieza de código más interesante y valiosa que escribe.

Terminar algo es una buena idea, pero no en un vacío. Si comienza una reescritura, entonces puede elegir terminar algo terminando un submódulo en particular. Podría establecer eso como un primer objetivo, después del experimento anterior. Terminar no tiene que significar terminar su proyecto principal inicial todavía. Después de finalizar un módulo, finalice otro, etc., hasta que termine de reescribir todo el alcance de su proyecto original, si lo desea.