¿Un programador tiene que poder codificar múltiples líneas de código sin ejecutarlas?

Echo de menos mis viejos tiempos en la Universidad, trabajando en un mainframe, donde para trabajar en nuestra práctica de informática tuvimos un número limitado de compilaciones … Mi compañero y yo hicimos un intérprete completo de lenguaje matemático y representación gráfica ( Mathlab no existía en ese momento, y el terminal era un VT100 con modo de gráficos ESC) en solo 3 compilaciones …

Depende de tu habilidad. Muchos programadores escribirán un componente completo “big bang” y luego intentarán compilarlo y probarlo. Si bien puede compilarse, a menudo encontrarán muchos errores o problemas y resolverlos es difícil cuando tiene muchas características escritas a la vez y se están probando todas juntas.

La cantidad de código que se escribe antes de la ejecución está directamente relacionada con la capacidad de saber con cierto grado de certeza de que se probará correctamente. Mi punto de vista es escribir el código para una característica, probarlo, validar que funciona y pasar a la siguiente. Incluso si pudiera escribir todo y hacer que se compilara y funcionara.

La razón no es la cantidad de código que se puede extraer en un período de tiempo determinado, sino más bien el tiempo necesario para ejecutarlo y probarlo para adquirir la confianza de que funciona según lo diseñado y esperado. ¿Codifica 5 funciones e intenta probarlas todas a la vez, sin saber cuáles están causando fallas? ¿O codifica 1 característica a la vez, la prueba y luego repite 5 veces?

El último enfoque le permite marcar una característica y luego centrarse en la siguiente. Es más eficiente y cada prueba posterior le permite generar confianza en el código que escribió anteriormente porque a menudo se prueba y se ejecuta nuevamente. Especialmente si las características adicionales dependen de las probadas previamente. Un enfoque muy “básico” o “de abajo hacia arriba” para escribir código.

Esto es más eficiente en el tiempo porque estás persiguiendo menos errores a la vez. Personalmente, no puedo soportar el estilo de desarrollo “big bang” debido a ese problema exacto. El menor tiempo dedicado a perseguir problemas significa más tiempo para resolver problemas. En general, mi observación ha sido que los desarrolladores con menos experiencia tienden a escribir “big bang” (todo el código a la vez) y los desarrolladores más experimentados tienden a escribir una característica comprobable a la vez y luego pasar a la siguiente. Los desarrolladores experimentados a menudo no tienen que volver al código que han escrito para solucionar los problemas como resultado.

Así es como puede mejorar mucho su programación en un tiempo relativamente corto:
– programa a tiempo completo, pero sin computadora la mayor parte del tiempo: lápiz y papel. Y al no tener una computadora, tampoco tiene internet ni documentación en línea. Sin embargo, puede usar libros o documentación impresa. Si necesita documentación, pídale a alguien que la imprima por usted (y se la entregue unos días después de que la solicite).
– solo acceda a una computadora 2 horas tres veces a la semana (lunes, miércoles y viernes). Cuando lo haga, solo tendrá acceso a un editor de texto simple (piense en el Bloc de notas en Windows o pico en unix / OsX). Sin internet ni documentación en línea (si lo desea, puede traer su documentación impresa al laboratorio de computación).
– cuando desee ejecutar el compilador o su programa, configure la compilación como un archivo por lotes o como un archivo de creación, prepare los datos de entrada a su programa como un archivo y configúrelo para que se ejecute con esa entrada desde un archivo por lotes. Déjalo allí para que alguien más corra. Obtendrá los resultados en su próxima sesión. Tanto la salida del compilador como, si la compilación tuvo éxito, la salida de su programa.

Así es como mucha gente aprendió a programar. Y era un programador más rápido y mejor en esos tiempos que ahora con Google e IDEs.

Sí, a veces tienes que hacerlo. A veces, ocurrirá que no puede compilar una función hasta que haya anotado una cantidad mínima de códigos. Todos los programadores lo enfrentan. Y no es una pesadilla 🙂

Si. Es posible que nunca necesite hacerlo, pero si no es capaz de hacerlo, eso significa que no puede mantener en su cabeza gran parte de lo que está haciendo. Esas son las personas que no pueden arreglar nada sin introducir dos nuevos errores. También están trabajando más lentamente una línea a la vez y muestra una grave falta de confianza en depender tanto del compilador.

De hecho, argumentaría que, si no puede escribir un programa completo sin un compilador a mano, tendrá problemas. El programa no necesita funcionar , por supuesto, pero debería estar bastante claro lo que está tratando de hacer y solucionarlo no debería requerir comenzar desde cero.

Lo que significa que probablemente sea mejor pensarlo como un diagnóstico en lugar de una habilidad laboral. Todavía hay casos en los que el código de construcción y prueba tiene mucha sobrecarga, por lo que no puede perder el tiempo haciéndolo en proyectos triviales, pero esa es una situación relativamente rara.

Mejora con la práctica, independientemente. Trabaje en papel y ejecute el programa “manualmente”, haciendo un seguimiento de lo que hay en cada variable.

Depende de su familiaridad con el idioma y las capacidades del idioma y el depurador.

A veces tienes herramientas pobres y poco conocimiento, y puedes cambiar UNA LÍNEA a la vez y volver a ejecutarla.

O si sabe lo que está haciendo y tiene buenas herramientas y un buen compilador de idiomas que es realmente útil, puede escribir una página de código a la vez y tener la oportunidad de que funcione con solo unos pocos ajustes.

Todo depende.

En lenguajes muy flojos como JavaScript, efectivamente NO hay errores que JavaScript pueda detectar de inmediato, así que a menudo cambio una PALABRA a la vez y presiono actualizar y taparme los ojos.

Depende de la cantidad de líneas, pero esencialmente, sí. A menos que esté probando en gran medida cada función a medida que avanza (tal vez usando REPL), es muy probable que escriba varias funciones en cada pase de escritura antes de probar / probar.

Al escribir esta respuesta, tengo la intención de escribir todo de una vez y seguir el flujo de mi respuesta en mi cabeza mientras lo hago. Una vez que haya cubierto todos los puntos que quería hacer, volveré y lo volveré a leer.

Entonces, ¿cuánto lenguaje natural escribirías antes de volver y comprobar qué fue lo que hiciste?

Lo mismo con escribir código, solo compilarlo es la parte de “relectura”.

Seguro. Cuando configuro algo nuevo, a menudo escribo hasta unos cientos de líneas antes de intentar ejecutarlas / probarlas.

Puede hacerlo porque se encuentra en un entorno en el que compilar / implementar el código llevaría un tiempo y no desea perder el tiempo. Del mismo modo, si probar / ejecutar el código implicaría una gran cantidad de desorden en la interfaz de usuario (suponiendo que no se estén realizando las pruebas automatizadas / unitarias adecuadas), es posible que desee guardarlo para más adelante. O bien, está bastante seguro de que el código funcionará más o menos de inmediato (o será lo suficientemente fácil de depurar), por lo que desea eliminar la escritura de una vez antes de configurarlo para probarlo y depurarlo. Es posible que el código no sea útil en pequeñas cantidades (dependiendo de cómo esté configurado con las pruebas unitarias y demás), por lo que debe tener una buena base de base antes de intentar ejecutar algo que esté muy cerca de su objetivo final .

Normalmente, respondería que no. Sin embargo, la capacidad de escribir varias líneas de código sin ejecutarlas viene con experiencia. Más adelante, según el idioma, aprenderá a ejecutar y depurar paso a paso, y no tendrá que analizar continuamente el código para probar si funciona.

“Tener que” siempre es difícil, y la respuesta es casi siempre no. ¿Debería un desarrollador poder codificar múltiples líneas de código sin ejecutarlas? Sí, pero nunca debe verificar el código que ha escrito que no ha ejecutado y probado.

Absolutamente, especialmente en bases de código grandes donde los tiempos de compilación pueden ser bastante largos.

Viene con experiencia y en realidad es mucho más fácil de lo que piensas. Todos cometemos errores, desde errores lógicos hasta errores de sintaxis, solo se mejora al verlos antes de que se vuelvan problemáticos con la práctica.

Depende de si está escribiendo bajo presión o libre albedrío.

A medida que aprende más, pasa de hit y trial a – escribir con confianza clase / métodos / utilidades / etc. sin ejecutar hasta que los módulos tengan suficiente cobertura …

Por otro lado, si está obsesionado con TDD, estaría generando código y pruebas, lo que puede implicar muchas ejecuciones de prueba.

Esto viene con el tiempo. Cuando adquieres experiencia en un idioma y tecnología, comienzas a hacer pruebas con más frecuencia. Aún así, el mejor enfoque es escribir sus pruebas antes del código real; seguir iniciando la aplicación es un gran gasto de tiempo, ya que necesita iniciar sesión, completar formularios, etc. Lea algo sobre TDD, evite algunas de las advertencias y todo saldrá de forma natural.

Definitivamente debería poder escribir una línea de código y estar 95% seguro de que hace lo que espera que haga; La mayoría de los errores principales deben provenir de la lógica y no de la sintaxis. Dicho esto, constantemente compilo y ejecuto mi código para tratar de detectar problemas de inmediato, así que estoy cavando a través de 10 líneas de código cuando algo se rompe, no 100.

Seguro. Al menos escriba el método o procedimiento completo antes de ejecutar el código.

¿Líneas?
Sí, por supuesto !

si considera alimentar a su familia adecuadamente como programador, es mejor que entrene su cerebro para ejecutar el código.