Estoy reescribiendo mi código unas 10 veces antes de terminar. ¿Esto esta mal?

Question

Cuando comienzo a escribir algo complejo, me parece que reinicio la escritura como 10 veces antes de terminar con lo que quiero, a menudo descartando cientos de líneas de código.

¿Estoy haciendo algo mal o otros tienen flujos de trabajo como este?

EDITAR: En este momento, estoy trabajando en un compilador modular. El último proyecto en el que estaba trabajando era un servidor en Java. Antes de eso, era algo de simultaneidad.

Hago un poco de planificación, y nunca comienzo a codificar antes de tener interfaces para todo.

Dado que, ¿es normal simplemente limpiar la pizarra de forma repetida?

Answer 1

Descartar muchas líneas de código suele ser un aspecto positivo de la refactorización. Eso es genial. Pero comenzar más de diez veces significa que probablemente no haya analizado su problema y solución. Está bien retroceder y algunas veces comenzar de nuevo, pero no tan a menudo. Debería diseñar su código de tal forma que cuando retroceda y refactorice, conserve la mayor parte de lo que creó porque existirá en fragmentos lógicos y muy bien aislados. (Utilizando un lenguaje vago ya que no se especificó el idioma de elección).)

De Comentario del autor:

Normalmente reinicie porque consigo confundido por todo lo que pasa en mi código.

Estudie su oficio y haga un buen uso de los patrones de diseño y otras filosofías de programación para darle a su código una estructura bien definida ... algo que reconocerá meses e incluso días por el camino.

Answer 2

En un problema complejo, esto es común. Si no está apuñalando completamente en la oscuridad, realmente ayuda dibujar nuestras ideas primero, pero nuevamente está moviendo los 'reintentos' de código a papel.

Si te ayuda a llegar a una buena solución, ¿cómo puede ser malo?

Answer 3

Depende de qué tan bien conozca el espacio problemático. Si es un territorio familiar, entonces me preocuparía si tomara 10 iteraciones. Si se trata de un territorio desconocido, puede llevar hasta 10 iteraciones, pero al menos algunas de ellas se reducirán a prototipo, o un intento de prototipo, antes de descartarse.

Answer 4

Perfectamente normal. No importa cuánto planifique, muchas veces tengo un "¡Ajá!" momento una vez que las manos tocan el teclado.

Con la misma frecuencia es un "¿Qué demonios estaba pensando?" momento.

Todo está bien. Estás haciendo un mejor código.

Answer 5

Si está comenzando algo complejo, un poco de planificación antes de que empiece a escribir parecería una buena idea.

Diseño primero.

Answer 6

Si está aprendiendo algo con cada iteración, probablemente no haya un problema. Las fechas límites y las cosas molestas como esa pueden hacer su vida un poco más difícil. :)

Cuando estoy trabajando en un nuevo problema, me gusta pseudocódigo en los comentarios en el controlador de función real, como parte de la generación del stub para mi TDD. Luego agregue el código en cada paso que tenía en los comentarios del cuerpo de la función.

Me ayuda a mantenerme enfocado en lo que el problema que estoy resolviendo es, y no perderme en los detalles temprano.

Answer 7

El cambio más importante que puede hacer para ayudarse a sí mismo sería a planifique primero su código. En papel.

Su plan no tiene que ser súper profundo (aunque a veces eso también es bueno). Solo esboce una idea aproximada de lo que quiere que haga su programa. Anote los puntos clave de funcionalidad. "Quiero que haga esto, esto y esto".

Una vez que tenga eso, diseñe un diseño aproximado. Clases, métodos, funciones, objetos. Dale un poco de forma. Haga una asignación aproximada de funcionalidad a varias partes de su diseño.

Dependiendo de la naturaleza del proyecto, podría tomar un diseño aproximado como ese y convertirlo en un diseño mucho más detallado. Si es un proyecto pequeño, tal vez no. Pero no importa la complejidad proyectada, el tiempo invertido en diseñar lo recompensará con un mejor código y menos tiempo dedicado a la codificación. Si tiene errores obvios que requieren que refactorice grandes porciones de su programa, deberían ser evidentes en su diseño inicial y puede ajustarlo. No habrá desperdiciado cientos de líneas de código en un error obvio.

Answer 8

Considere aprender un marco en cualquier idioma que esté utilizando (o en cualquier idioma).

Creo que los marcos de aprendizaje hicieron que mi código sea un millón de veces mejor. Al aprender los marcos (y lo que es más importante, cómo funcionan), aprendí no solo los patrones de diseño, sino cómo implementarlos de manera realista.

Considere mirar rails, cakephp o django (suponiendo que está en un lenguaje de script, no conozco ningún framework de lenguaje de escritorio. ¡Lo siento!). Luego vea cómo encajan sus piezas.

Answer 9

Todas las sugerencias aquí son válidas, sin embargo, recuerde que hay un momento en la vida útil de un programa que es "lo suficientemente bueno". Es fácil caer en una trampa de refactorización interminable, solo porque veas que "sí, ¡esto podría hacerse mejor!". Bueno, en serio: a menos que tu programa tenga solo unas pocas líneas, SIEMPRE hay una forma de hacerlo mejor.

Creo que hay programadores felices por ahí que no sufren de eso, pero al menos tengo que seguir recordándome a mí mismo que hay una línea que se llama "lo suficientemente buena".

Y es especialmente cierto si está escribiendo código para otra persona, nadie notará que hizo algo "mejor", todo lo que cuenta es "¿funciona bien?".

Además, una práctica MUY BUENA es al menos para que funcione antes de volver a escribir. Entonces siempre puede recurrir a una solución previa de trabajo.

(desde hace 12 años estoy constantemente reescribiendo un juego que estoy escribiendo, y no estoy ni cerca del final ...)

Answer 10

Los compiladores son aplicaciones muy complejas, y no se puede escribir un compilador de optimización de principio a fin de una sola pasada, sin importar cuánto se le dedique al principio. Por lo general, intenta hacer que algo funcione correctamente de principio a fin y luego volver a modularizarlo y agregar nuevas características como optimizaciones. Este proceso significa mucha refactorización y reemplazo de secciones enteras por completo. Esto también es parte de los procesos de aprendizaje, ¡ya que nadie puede saber todo y recordarlo!

(También estoy trabajando en un compilador .NET como parte del proyecto MOSA -. Www.mosa-projet.org)

Answer 11

a resolver su problema en el papel. . . no tengas tanta prisa por escribir.

Answer 12

Hay dos situaciones. (1) Pude planificar con confianza y aislar mis abstracciones. (2) No tengo.

Para (1), una técnica efectiva es colocar versiones ficticias de ciertas clases o funciones solo para manejar el resto del código. (o por el contrario, escribir dichas clases y funciones y conducirlas con un script de prueba.) Esto le permite abordar solo parte de la complejidad en cada pasada.

Por mucho que todo el mundo diga que la gente debe planificar con anticipación, a menudo no funciona de esa manera, lo que da como resultado la situación (2). Aquí, tenga cuidado de administrar lo que está tratando de lograr en una iteración de código. Tan pronto como encuentre que su cerebro no puede hacer malabares con todas las cosas que está haciendo, reduzca su ambición hacia lo que desea lograr antes de la próxima compilación y prueba. Permita que su código sea defectuoso pero fácil de escribir en la primera pasada, y luego desarrolle a través de la refactorización. Esto mejora la eficiencia al limpiar varias veces la pizarra.

Por ejemplo, una forma en que solía meterme en líos era oliendo código común y refactorizando en subrutinas demasiado pronto, antes de saber realmente la forma del código. Desde entonces he comenzado a permitirme duplicar el código en la primera pasada, y luego volver atrás y descomprimirlo en subrutinas más adelante. Ha ayudado tremendamente.

Answer 13

Se llama refactoring buddy y es bueno, solo necesita limitarlo para que no pierda el código de refactorización de tiempo que tiene y está trabajando en lugar de escribir un código nuevo.

Algunas de las razones por las cuales uno debe refactorizar son:

• que mejoran el rendimiento.
• Código de organización.
• Necesita escribir su código de una manera diferente para que algo funcione.
• Hacer algo de otra manera porque ahorra mucho trabajo (es decir, usando MXML en lugar de ActionScript).
• Ha utilizado el nombre incorrecto para una variable.