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?
fuente
#define h for(int c=y-3; y; c++/(randomTypeIDefinedEarlier)s*(float)4*(lol)sin((helloWorld)mysub(2,1,++a,*(r+z))); goto xkcd)y esa es solo una línea.Respuestas:
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.
fuente
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.
fuente
Me gusta escribir mi prueba antes de escribir mi código de implementación. Me gusta esto por tres razones:
fuente
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.
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.
fuente
Recopilo y pruebo si se cumple una de las siguientes condiciones:
fuente
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.
fuente
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.
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente
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.
fuente