¿Cómo programar algo con la expectativa de que funcionará la primera vez?

7

Tenía un amigo en la universidad que programó algo que funcionó la primera vez, fue bastante sorprendente. Pero en lo que a mí respecta, simplemente enciendo el depurador tan pronto como finalmente comprendo lo que estoy trabajando para compilar, me ahorra tiempo (por supuesto, muchas veces tengo un poco de esperanza o uso un montón de depuración premeditada cuerdas).

¿Cuál es la mejor manera de abordar el ideal de Dijkstrain para nuestros programas?

-o--

¿Esto es solo un tipo de búsqueda de la grandeza de locos en el cielo, aplicable solo a tareas finitas que nadie debería esperar en nuestra vida profesional porque la programación es demasiado compleja?

    
pregunta Peter Turner 06.01.2011 - 16:18

11 respuestas

5

Haga componentes pequeños con sus propios arneses de prueba independientes que demuestren que cada pieza funciona. Hacer que un programa funcione por primera vez es solo una cuestión de juntar componentes (me refiero a "piezas", no estoy hablando de alguna tecnología de componentes en particular) que ya funcione.

    
respondido por el Dan Rosenstark 06.01.2011 - 16:51
6

"Simplemente enciendo el depurador tan pronto como finalmente comprendo lo que estoy trabajando para compilar, me ahorra tiempo". Esto me asusta de tantas maneras.

Sí, tengo frecuentemente con pequeños módulos. Las características completas o el subsistema son realmente difíciles de corregir a la primera.

"¿Es esto solo una especie de locos viejos en la búsqueda de la grandeza aplicable solo a tareas finitas que nadie debería esperar en nuestra vida profesional porque la programación es demasiado compleja"

En realidad, creo que este SIEMPRE debería ser su objetivo principal al escribir software. Demasiados programadores abusan del hecho de que es bastante fácil simplemente cambiar un fragmento de código y recompilarlo. Este método NO debe ser su forma principal de resolver problemas de software. Todos cometen errores, pero si regresa a un módulo más de tres veces para arreglar algo, entonces tiene un defecto de diseño o no tiene idea de qué código se supone que debe hacer su escritura.

Hay cierto margen de maniobra si estás aprendiendo una nueva tecnología.

    
respondido por el Pemdas 06.01.2011 - 16:26
5

Sí, ha habido numerosas tareas universitarias y funciones de aplicaciones en el trabajo que solo funcionaron la primera vez que lo intenté. No sucede siempre, pero sucede.

No hay mucho para eso. Simplemente se trató de tener un buen control de lo que estaba haciendo y no apresurar la implementación. Estar muy familiarizado con otras partes del programa también me ayudó, ya que no era tan susceptible a las suposiciones sobre el código de otra persona.

    
respondido por el Adam Lear 06.01.2011 - 16:26
2

Por supuesto que tengo, ¡el primero!

10 print "mattias"
20 goto 10

Pero con toda seriedad, ¿por qué querrías hacerlo? La programación es un proceso incremental, hacerlo de una sola vez es como comer un melón de un trago.

    
respondido por el Homde 06.01.2011 - 16:22
2

Fíjate en Test Driven Development TDD. Por la naturaleza de escribir una prueba antes del código, nunca funciona la primera vez. :-)

TDD es probablemente el mejor marco para escribir código confiable de calidad. Tiene la mejor cobertura de prueba y por su diseño reduce la cantidad de código "qué pasaría si". Ya que tiene que escribir una prueba antes de escribir código, también IMO reduce la cantidad de funciones adicionales que las cosas de un programador son "geniales", ya que el desarrollador tiene que crear un escenario de prueba completo alrededor de esa función genial pero innecesaria.

    
respondido por el Bill Leeper 06.01.2011 - 17:32
2

Con frecuencia he escrito programas no triviales (~ 200 LOC o algo así), los ejecuté y funcionaron la primera vez. Como han mencionado otros, es útil escribir de forma modular para que pueda tener la confianza de que cada pieza funcionará según lo previsto.

Escribir programas modulares requiere planificación. Paso casi la mitad de mi esfuerzo cognitivo al principio solo pensando en el problema. También ayuda que he estado programando por más de 30 años; muchas técnicas de programación comunes se han convertido en patrones y las escribo sin pensar mucho.

Hago mis mejores hoyos en uno con un lenguaje que no se interpone en mi camino: Perl. Su sintaxis flexible me permite plasmar mis ideas rápidamente sin mucho alboroto. Los tipos débiles y dinámicos significan que no tengo que preocuparme por declarar variables antes de usarlas, ni tengo que preocuparme por las fugas de memoria y las estructuras de datos de tamaño correcto. Simplemente trabajan y puedo ponerme a trabajar.

Un patrón común es el que se desplaza a través de un archivo de texto, ignorando comentarios, recortando espacios en blanco y descartando líneas en blanco. El resto se pone en una matriz.

while (<>)
{
    s/#.*$//;          # Trim comments
    s/^\s+|\s+$//g;    # Trim blanks
    next if (/^$/);    # Discard blank lines
    push @lines, $_;
}
    
respondido por el Barry Brown 06.01.2011 - 19:06
1

Para mí, normalmente ocurre con componentes únicos de complejidad bastante simple. Creo que es un buen ejercicio para hacer de vez en cuando, ya que te obliga a pensar completamente el "flujo" de tu código en lugar del método de compilación y ajuste. También lo hace más rápido a largo plazo, ya que con el tiempo mejorará al escribir código limpio desde el principio y, por lo tanto, dedicará menos tiempo a arreglar las cosas. Si dependes constantemente del compilador, siempre tendrás la sobrecarga asociada con "ajustar / compilar".

    
respondido por el Heath Lilley 06.01.2011 - 16:26
1

La depuración constante para ver si el código que acaba de escribir funciona correctamente tiende a perder tiempo en mi opinión. Puede ser necesario ocasionalmente, pero si el código no es lo suficientemente simple como para pensar en ello, me resulta más productivo escribir pruebas automatizadas. Luego, solo puede ejecutarlos / modificarlos a medida que codifique y ver si sus afirmaciones son verdaderas.

    
respondido por el Matt H 06.01.2011 - 16:48
1

Eche un vistazo al capítulo "Cómo escribir programas correctos" de "Programming Pearls" de Jon Bentley, particularmente la sección 4.2. Personalmente, no puedo imaginar ir a este nivel de rigor en cada cosa que escribo, pero creo que es un buen ejemplo del tipo de pensamiento que debes hacer para hacerlo bien la primera vez.

    
respondido por el AShelly 06.01.2011 - 20:51
1

Cuando estoy trabajando en Smalltalk, hago casi todos mi desarrollo en el depurador.

Escribo una prueba que falla, demostrando el comportamiento correcto del código que todavía no se ha escrito, y presiono el botón Ir en el corredor de prueba. La prueba falla. (¡Si no falla, primero descubro por qué!) Hago clic en la prueba y aparece el depurador. Paso a donde sea que esté el problema, escribo lo que necesito hacer para hacer que la prueba pase, defina una clase, escriba un método, lo que sea, y luego presione "proceder". Con suerte, la prueba ahora pasa. Si no es así, retrocedo la pila de llamadas para averiguar dónde cometí el error y continúo ejecutando la prueba.

Después de que termine, normalmente ejecuto toda la suite, solo para asegurarme de que no rompí nada.

    
respondido por el Frank Shearar 07.01.2011 - 23:46
0

Para mí, todo lo que escribo solo funciona la primera vez, ¿no es eso lo que le sucede a todos los demás?

Con toda seriedad, la programación es como escribir con los ojos cerrados, cuanto más escriba, más probabilidades tendrá de cometer un error y más tardará en encontrarlo. Si tiene especial cuidado, puede escribir un trato justo, pero si no puede estar seguro de que es correcto, ¿cuál es el punto?

    
respondido por el dan_waterworth 06.01.2011 - 16:44

Lea otras preguntas en las etiquetas