¿Con qué frecuencia ejecuta y prueba su código mientras programa? [cerrado]

Especialmente cuando escribo código nuevo desde cero en C, me encuentro escribiendo código durante horas, incluso días, sin ejecutar el compilador para otra cosa que no sea una comprobación de sintaxis ocasional.

Tiendo a escribir fragmentos de código más grandes con cuidado y realizar pruebas exhaustivas solo cuando estoy convencido de que el código hace lo que se supone que debe hacer al analizar el flujo en mi cabeza. No me malinterpreten: no escribiría 1000 líneas sin probar en absoluto (eso sería apostar), pero escribiría una subrutina completa y la probaría (y arreglaría si fuera necesario) después de que creo que he terminado.

Por otro lado, he visto en su mayoría novatos que ejecutan y prueban su código después de cada línea que ingresan en el editor y creo que los depuradores pueden ser un sustituto del cuidado y la cordura. Considero que esto es una gran distracción una vez que has aprendido la sintaxis del lenguaje.

¿Cuál crees que es el equilibrio correcto entre los dos enfoques? Por supuesto, el primero requiere más experiencia, pero ¿afecta la productividad de manera positiva o negativa? ¿El segundo te ayuda a detectar errores a un nivel más fino?

REALMENTE depende del aspecto del proyecto en el que estés trabajando.

• Cuando hago algo con OpenGL (que funciona como una máquina de estado), constantemente compilo y ejecuto para asegurarme de que no arruiné nada accidentalmente. Establecer un valor sin recordar restablecerlo al final de una función puede hacer que la aplicación muestre solo una pantalla en negro.

• Para el desarrollo a gran escala "bajo el capó", trato de obtener tantas pruebas como sea posible de antemano. Como las pruebas pueden decirme más fácilmente qué se rompió, puedo pasar un tiempo sin tener que esperar la compilación típicamente larga.

• Para el diseño UX, utilizo algún tipo de diseñador visual, que siempre se ve de la forma en que se ejecutará (o cerca de él). Esencialmente, siempre está compilando el código de diseño.

Personalmente, debo trabajar en pequeños fragmentos porque no soy lo suficientemente inteligente como para guardar horas de codificación en mi caché L1 biológico. Debido a mis capacidades limitadas, escribo métodos pequeños y cohesivos y diseño objetos para tener un acoplamiento muy flojo. Las herramientas y los lenguajes más potentes facilitan la codificación por más tiempo sin compilar, pero todavía hay un límite para mí.

Mi preferencia es escribir una pequeña pieza, verificar que funcione como esperaba. Entonces, en teoría, soy libre de olvidar los detalles de esa pieza y tratarla como una caja negra tanto como sea posible.

Me gusta escribir mi prueba antes de escribir mi código de implementación. Me gusta esto por tres razones:

1. Escribir mi código de prueba de antemano me ayuda a pensar cómo se debe usar mi código. Me ayuda a pensar en casos extremos que no pensé cuando estaba diseñando originalmente mi programa.
2. Sé que terminé de escribir el código de implementación cuando pasan todos mis casos de prueba.
3. Tener el hábito de escribir pruebas antes del código también tiene el efecto adicional de poder probar que su código no ha agregado ningún error nuevo (suponiendo que haya escrito buenos casos de prueba).

Me encuentro escribiendo código durante horas, incluso días, sin ejecutar el compilador para otra cosa que no sea una comprobación de sintaxis ocasional.

Horas a días: es una señal clara de que pierde la capacidad de descomponer su código en fragmentos más pequeños que se pueden verificar y probar por sí mismos. Definitivamente deberías trabajar en eso.

Tiendo a escribir fragmentos de código más grandes con cuidado y realizar pruebas exhaustivas solo cuando estoy convencido de que el código hace lo que se supone que debe hacer al analizar el flujo en mi cabeza.

En lugar de escribir fragmentos de código más grandes, y por lo tanto complicados, que necesitan horas para analizarse en su cabeza, debe intentar crear bloques de construcción más pequeños y no tan grandes. Esto se llama construir abstracciones , y esa es la esencia de una buena programación, definitivamente no es una señal de ser un novato.

Una programación excelente es como un excelente juego de Billard: un buen jugador no juega golpes duros. En cambio, juega de una manera en la que después de cada golpe las bolas se detienen en una posición donde el siguiente golpe es fácil nuevamente. Y un programador no es bueno porque puede escribir código complicado, es bueno porque puede evitar escribir código complicado.

Recopilo y pruebo si se cumple una de las siguientes condiciones:

• La última compilación fue hace 15 minutos.
• La última compilación fue hace 25 líneas.
• Se ha implementado una nueva función / subrutina
• Cambio mayor
• Nueva función (o un error disfrazado de función)
• Corrección de errores (se eliminó una "característica")
• Estoy aburrido

La frecuencia con la que ejecuto y pruebo el código depende del idioma con el que estoy trabajando en ese momento. Si estoy codificando un procedimiento almacenado, generalmente esperaré hasta que todo esté allí.

Por otro lado, si estoy codificando en Lisp, probaré cada función después de escribirla.

Si estoy codificando en Haskell, normalmente haré una compilación después de cada función para detectar cualquier tipo de error y ejecutaré el código después de que todo esté hecho.

Escribo el código suficiente para que la prueba llegue a verde. Eso significa que ejecuto la prueba cada pocos minutos. Ese es mi estilo C ++. Sin embargo, en Ruby utilizo la prueba automática, así que cada vez que presiono guardar, recibo comentarios de las pruebas a través de una buena ventana emergente. Ni siquiera dejo de escribir código, simplemente sucede en segundo plano.

Tres veces por hora, lo necesite o no.

Hacemos primero la programación de prueba y confirmamos solo el código de trabajo para el VCS. El smolderbot va y revisa el repositorio cada 20 minutos y ejecuta el conjunto de pruebas. Cualquier falla se envía inmediatamente a todo el equipo de programación para su reparación inmediata.

Para mí no se trata de cuánto escribo. Puedo escribir miles de líneas de código simple sin tener que probarlo. Pero cuando escribo código más difícil, tiendo a probar cada función individualmente después de haber escrito un conjunto coherente de ellas.

Sin embargo, a veces, ver su código en ejecución es un gran impulso de motivación, cuando no ha ejecutado nada en un tiempo, es bueno verlo funcionar.

Para mí; -
Línea de tiempo corta (no hay mucho tiempo para pensar) - escribir código, compilar, probar. depuración Tiempo
suficiente - mientras (hecho) {escribir código pequeño, compilar}, probar, depurar

Pruebo para cada concepto de codificación. Algunas veces esta es una función o clase y otras no es más que una declaración if. Una vez que el concepto funcione, pase al siguiente.

Intento escribir pruebas antes del código. Ejecuto mis pruebas al menos dos veces antes de una confirmación. Luego se ejecuta nuevamente con el servidor de integración continua.