¿Hay algún beneficio en compilar su código a medida que avanza?

183

Recientemente tuve una entrevista de trabajo en la que me dieron una hora para escribir un código real. No fue una gran cantidad, probablemente menos de 100 líneas. Después de unos 45 minutos, lo compilé, lo ejecuté y lo puse a trabajar. Es posible que haya pasado entre 5 y 10 minutos resolviendo errores de compilación y un par de errores menores, pero en general fue muy sencillo. (Por cierto, recibí una oferta de ellos).

Sin embargo, lo que me dejó perplejo fue que después de entregar el código completo, el entrevistador me dijo que lo único que hice mal fue "no compilar a medida que avanzo". Le pregunté cuál es la diferencia, y él dijo "qué hubieras hecho si hubieras terminado el código y no se hubiera compilado a tiempo".

Según tengo entendido, ese es un argumento no válido, porque "hacer que el código se compile" para una determinada longitud de código generalmente implica la fijación de un número constante de errores de compilación y lleva una cantidad de tiempo bastante constante, que debería ser lo mismo si lo hace después de usted termine de escribir el código, o si lo intercala con su tiempo de codificación. En todo caso, interrumpir su codificación para buscar puntos y comas faltantes probablemente sería perjudicial para su eficiencia. Excepto en circunstancias extremas cuando estoy experimentando con obscuridades alrededor de casos extremos en cosas como funciones virtuales en clases derivadas, etc., parece razonable esperar que el código escrito por un desarrollador experimentado compile, menos el error de tipeo ocasional, e incluso si no es así, '

En otro incidente similar, me dieron una base de código incompleta en una entrevista y me pidieron que terminara y realizara las modificaciones necesarias para que funcione. Comencé leyendo el código existente, y luego de unos minutos (incluso antes de terminar de mirar el código), el entrevistador me dijo que eso era suficiente. Cuando le pregunté qué habría hecho (es decir, "qué hice mal"), me dijo que habría comenzado obteniendo inmediatamente el código para compilar.

¿Por qué es eso relevante? En mi opinión y en mi experiencia, si una pieza de código se compila o no es esencialmente aleatoria, involucra cosas como si faltan o no puntos y coma, y ​​tiene poco que ver con la corrección del programa subyacente. (Para mí, centrarse en la compilación es como ejecutar un artículo a través de un corrector ortográfico sin corregir para revisar la gramática).

Si me das un código incompleto, lo primero que haré será leerlo. Ni siquiera intentaré compilarlo hasta que sepa qué está haciendo el código y sé que el algoritmo es correcto.

De todos modos, estos han sido solo un par de incidentes recientes, pero en general he escuchado a muchos desarrolladores hablar sobre la compilación de su código a medida que avanzan, y sin embargo, nadie ha podido decirme el beneficio de hacerlo. Entiendo los beneficios de probar su código a medida que avanza, pero ¿por qué compilar?

Entonces mi pregunta es esta: ¿hay algo que me haya perdido? ¿Existe realmente un beneficio compilar a medida que avanza? ¿O es algún tipo de mito propagado por la comunidad del software que debe compilar su código con frecuencia?

CaptainCodeman
fuente
54
O eso, o que mis hábitos son llamados malos hábitos por personas que tienen hábitos diferentes.
CaptainCodeman
99
@DocBrown La comparación es válida si el objetivo final es tener un producto correcto. Un programa que "se ejecuta" no es mejor que un programa que se ejecuta incorrectamente. No puede esperar que la compilación verifique su código por usted más de lo que puede esperar que un corrector ortográfico corrija sus errores gramaticales.
CaptainCodeman
77
Si la compilación perturba su flujo de trabajo es muy subjetiva y depende del idioma, el entorno de construcción, el tamaño / complejidad del proyecto, etc. Es más probable que la OMI sea un problema en grandes proyectos heredados.
pjc50
64
Estoy totalmente de acuerdo con el OP. No puedo entender cómo alguien puede juzgar sobre los hábitos de trabajo de uno, por ejemplo, cuando él / ella usa para iniciar el compilador. Lo único que cuenta es el resultado de los esfuerzos. ¿Es correcto? ¿Es mantenible? ¿Funciona en el plazo esperado? ¿Cuánto tiempo llevó implementarlo? Estas son las preguntas interesantes. Todo lo demás es arbitrario BS. Si el entrevistado escribe un código perfecto de 2 horas que se compila en el primer intento, ¿dónde está el problema? ¿Solo porque el entrevistador lo hace de manera diferente? Mi Dios.
JensG
99
También se debe mencionar que para ciertos lenguajes e IDEs (Java / [Eclipse | NetBeans | etc], C # / Visual Studio, ...), el IDE ya está compilando todo en segundo plano en tiempo real, mientras escribe, en efecto que le da un bucle de retroalimentación inmediata sobre si ha cometido un error. Uno esperaría que los desarrolladores de IDE tuvieran alguna investigación que respaldara este enfoque de compilación sobre la marcha.
Ogre Psalm33

Respuestas:

223

¿Existe realmente un beneficio compilar a medida que avanza?

Ahi esta. Le proporciona un ciclo de retroalimentación más corto, que en general, cuando se diseña (interfaz de usuario, software de escritura, diseño visual, etc.) es algo bueno.

Un ciclo de retroalimentación corto significa que puede corregir rápidamente los errores desde el principio, antes de que se vuelvan más caros de corregir.

Para tomar prestado su ejemplo, digamos que estaba codificando en un lenguaje tipo C y olvidó uno }en algún lugar en el medio del programa.

Si compila justo después de terminar de escribir la declaración, puede estar seguro de que acaba de introducir el error de compilación y puede solucionarlo allí y luego, en cuestión de segundos.

Sin embargo, si no lo hace, tendría que pasar una buena cantidad de tiempo leyendo el código, buscando la posición exacta en la que se }encuentra y asegurándose, una vez que haya localizado el error, de que la solución es realmente lo que se pretendía. Esto ocurriría un tiempo después de que dejaste ese bit de código. No sería tan claro como el cristal en el momento en que lo escribió.


Ahora, sí, el resultado final es el mismo, pero usted perdió una buena cantidad de tiempo en problemas sintácticos con los que el compilador está allí para ayudarlo, una cantidad de tiempo que podría ser significativamente más corta si compila a medida que avanza.

Oded
fuente
72
De hecho, para errores sintácticos como ese, los IDE modernos esencialmente compilan y recompilan todo el tiempo para hacer que su ciclo de retroalimentación sea lo más corto posible, y es irrazonablemente útil para detectar errores menores.
Phoshi
12
@CaptainCodeman: diría que hay algunos errores de compilación que requerirían que revises una gran cantidad de código. Esto es más cierto para bases de código más grandes y conjuntos de cambios más grandes.
Oded
29
A veces, el compilador le ofrece un rompecabezas en lugar de una pista, como los errores de la plantilla gcc.
pjc50
14
@ pjc50: absolutamente (lo cual es más fácil de manejar al no cambiar demasiadas cosas a la vez antes de la próxima compilación, para que sepa exactamente lo que ha cambiado por fin).
Doc Brown
21
La idea no es solo compilar al azar. Es compilar en cada paso significativo, compilar cuando se espera que siga funcionando correctamente. Por ejemplo, compilaré para probar para asegurarme de que los objetos se crean / eliminan correctamente, o para asegurar que los eventos se disparen correctamente a una nueva clase que creé. Si creo una clase y la engancho a mi programa de alguna manera, quiero asegurarme de que lo hice correctamente antes de conectar más cosas a mi aplicación. Menos importante con aplicaciones pequeñas, vital para las grandes.
Thebluefish
108

La compilación es una forma de prueba, especialmente en idiomas que hacen un uso extensivo de tipos como Haskell o ML . En otros idiomas es un escaneo sintáctico que le dice poco.

Dicho esto, "compilar sobre la marcha" me parece un hábito muy situacional. Igualmente podría ser rebajado por ser "nervioso" por compilar con más frecuencia que el prejuicio personal del entrevistador. Suena como nitpicking; a nadie le gusta admitir que un entrevistado ha superado la prueba; inclina la balanza de la negociación salarial.

No todos los sistemas de compilación son rápidos. Trabajé en un proyecto (C ++), donde Make podría pasar 30 segundos solo stat 'ting todo para determinar si es necesario para construir o no, y la mayoría de los archivos tomaría un par de minutos para construir si se hubiera realizado cambios. Nos resistíamos a hacer esto con más frecuencia que cada 10-15 minutos. Sin duda, alguien proporcionará una anécdota de cuando compila involucrando tomar su mazo de tarjetas perforadas y llevarlas a un edificio diferente ...

Compila cuando sientas que has hecho una unidad conceptual completa en tu cabeza y estás listo para validarla. Una vez por minuto o una vez por semana, dependiendo del flujo de trabajo.

pjc50
fuente
25
cuando lleves tus tarjetas perforadas a los sysops para cargarlas, asegúrate de nunca dejarlas caer porque ponerlas de nuevo en el orden correcto es un verdadero PitA. Ah, para los días en que una herramienta de depuración esencial era una banda elástica.
gbjbaanb
3
Cuando comencé a programar, midí mi progreso según la cantidad de código que podía escribir sin compilar, esencialmente por la calidad de mi compilador mental. Al principio eran unos pocos personajes, luego unas pocas líneas. Ahora no me importa. Compilo mucho para pequeños cambios de los que solo quiero ver los efectos, compilo muy poco al hacer el diseño estructural del proyecto.
Phil
Hmm Solo quiero decir que un archivo C ++ bien escrito no debería tomar más de unos segundos para la compilación. Si es más largo, huele a mal código. Y si es tan grande que make tiene problemas, diría que la aplicación es demasiado monolítica. "Mi" marca nunca tuvo problemas, y no fue justo incluso cuando compilaba Linux.
phresnel
2
Era 1,5 millones de LOC cuando me fui. Tenga en cuenta que Linux es C no C ++; Las plantillas parecen ser lentas en gcc, y si ha hecho algo inteligente y útil que resulta lento de compilar, no hay una manera fácil de perfilar el compilador para que averigüe lo que fue.
pjc50
21
@gbjbaanb Creo que sería mejor decir "los días en que el control de fuente era una banda elástica". ;)
JasonMArcher
35

Entonces mi pregunta es esta: ¿hay algo que me haya perdido?

Sí: tu mente no es un compilador. Mientras que un compilador puede hacer n cambios de contexto por segundo, su mente no puede. El número de cambios de contexto que su mente puede hacer en un día depende de una serie de factores como la experiencia / familiaridad con la base del código, qué tan mentalmente inmerso está en el código, qué tan limpio es el código, qué tan complejo es el problema que está abordando, qué tan cansado está, si lo interrumpen con frecuencia o en un entorno ruidoso, etc.

Compilar una base de código (todo al mismo tiempo), por primera vez (piense en "proyecto con 20 archivos") lo obligará a cambiar el contexto de lo que está pensando (por ejemplo, "este valor se establece en 5 aquí, luego en for for loop blablabla, y el algoritmo complejo produce el valor correcto en el retorno ") a un problema de compilación que no tiene relación alguna con lo que está pensando (diferentes archivos / módulos / funciones / condiciones previas / sintaxis / nombres de variables, condiciones previas, etc. )

Cuanto más código compile a la vez, más cambios de contexto tendrá que hacer su mente. Esto no es un problema para una base de código pequeña, cuando todo el código que escribiste es lo que escribiste en una hora. Sin embargo, es un gran problema cuando se trabaja en una base de código existente, con interdependencias múltiples (y muchas veces no documentadas).

¿Existe realmente un beneficio compilar a medida que avanza?

Minimiza los cambios de contexto que su mente tiene que hacer, lo que le permite concentrarse más en el impacto y los efectos secundarios de los cambios que realiza. También lo hace menos cansado (y menos propenso a errores) y aumenta la calidad de su salida (es decir, puede garantizar efectos secundarios minimizados más fácilmente cuando cambia y compila un archivo a la vez, que cuando compila y cambia diez).

Si compila en iteraciones muy cortas (esto supone que el proceso de compilación está optimizado para tomar un tiempo breve), es posible corregir los errores de compilación sin salir de "la zona".

¿O es algún tipo de mito propagado por la comunidad del software que debe compilar su código con frecuencia?

También lo propaga la comunidad de software, pero tiene buenas razones para respaldarlo.

En mi opinión, ese es un argumento no válido, porque "hacer que el código se compile" para una determinada longitud de código generalmente implica la fijación de un número constante de errores de compilación y lleva una cantidad de tiempo bastante constante

Me parece que tiene poca (o ninguna) experiencia en el mantenimiento de bases de código heredadas medianas a grandes (cientos o miles de archivos fuente). Aquí es donde esta actitud (es decir, "compila a medida que avanzas") será de mayor ayuda, y aquí es donde se forma este tipo de hábito.

Me imagino que las personas que lo entrevistaron sacaron una conclusión similar ("tiene poca o ninguna experiencia en bases de código grandes").

utnapistim
fuente
1
"compilar y cambiar diez": muchas situaciones en las que esta es la unidad significativa más pequeña para probar; como agregar un nuevo parámetro a una función y a todos sus sitios de llamadas.
pjc50
77
El contexto cambia. Estás bromeando, ¿verdad? Si hablamos de compilación automática en segundo plano para indicar errores sintácticos en su código a medida que avanza, está bien. Pero el cambio de contexto más rápido no podrá decirle si la lógica del algoritmo está implementada correctamente o si el algoritmo es adecuado. Pero eso es lo que diferencia a una solución de trabajo de un código perfectamente organizado, compilado sin errores y un código rápido, pero completamente incorrecto.
JensG
55
@JenS, no, no estoy bromeando. Tener que saltar todo el código para corregir los errores de compilación asegura que ya no piense en el problema que está resolviendo actualmente (lo saca de la zona). Si, en cambio, puede compilar mientras escribe código, puede seguir trabajando para verificar el algoritmo, no la sintaxis. La forma más rápida de manejar los cambios de contexto es asegurarse de que no los necesitará). Sin embargo, mi publicación asume un mundo ideal (con la rápida compilación en C ++ de grandes bases de código y las interdependencias minimizadas).
utnapistim
1
@JensG que parece ser una falacia lógica: no se trata de elegir entre código compilado y código de mierda, sino de los posibles beneficios de compilar más de una vez.
Jorg
1
Dudo que la afirmación de que romper la concentración docenas de veces durante un corto período de tiempo para corregir errores sintácticos individuales sea más rápido que romperla una vez y corregir una docena de errores sintácticos de una sola vez (después de preocuparse por su algoritmo real). Ciertamente no es así como funcionan los cambios de contexto en informática (estamos tratando de optimizar el rendimiento después de todo aquí). Y he estado trabajando en un proyecto con aproximadamente 500k LoC de código C ++ que ha evolucionado durante más de una década, así que espero que todavía no saquemos la tarjeta de inexperiencia.
Voo
26

Creo que hay más que un poco de esnobismo profesional aquí. La implicación parece ser "si nunca ha tenido la necesidad de compilar regularmente, entonces nunca ha trabajado con algo tan complicado: obtenga más experiencia y regrese cuando haya aprendido a trabajar exactamente como nosotros".

Pero obviamente hay otro lado de esto. Algunos proyectos tardan en compilarse. He trabajado con marcos que tardan 30 minutos o más en compilarse incluso después de ediciones menores. Heaven te ayudará si alguna vez necesitas editar un archivo de encabezado. Las recompilaciones completas generalmente se realizan de la noche a la mañana, y si confía en el compilador para detectar sus errores, todavía hay errores raros que no se detectarán durante una compilación parcial. Simplemente no vuelve a compilar cada 5 minutos en estas condiciones, a menos que se sienta flojo .

El compilador no puede ayudarlo con errores lógicos o semánticos y los errores de sintaxis realmente no son tan difíciles de evitar que valga la pena pasar la mitad de su día compilando. Por supuesto, harás algún error tipográfico ocasional, pero voy a suponer que puedes escribir y leer. Si tiene la libertad de elegir, use un estilo de codificación que haga un buen uso del diseño para resaltar visualmente los errores y nunca volverá a soltar una llave, un corchete o un punto y coma nunca más. Se necesita un poco de práctica y un poco más de disciplina de lo que la mayoría está acostumbrada, pero es posible. Puedo escribir código durante un par de horas a la vez, en un editor de texto sin formato, y compilarlo por primera vez mejor que nueve de cada diez. Claro, podría compilar más a menudo, pero no recuerdo la última vez que tuve un error que habría sido más fácil de corregir como resultado.

Si no eres fanático de la recopilación constante, estás en buena compañía. Aquí está Donald Knuth:

En cuanto a su pregunta real, la idea de compilación inmediata y "pruebas unitarias" me atrae muy raramente, cuando me siento en un entorno totalmente desconocido y necesito comentarios sobre lo que funciona y lo que no. De lo contrario, se pierde mucho tiempo en actividades que simplemente nunca necesito realizar o incluso pensar.


Dicho todo esto ... si estás trabajando en un contexto donde la compilación es una acción gratuita, ¿por qué no? En casa, en proyectos personales, presiono ctrl-S aproximadamente una vez cada 30 segundos y el acceso directo de "compilación" casi con la misma frecuencia, en un IDE que ejecuta constantemente el código a través del front-end del compilador para proporcionar resaltado de errores en tiempo real. ¿Por qué dejar pasar un almuerzo gratis?

DeveloperInDevelopment
fuente
No estoy de acuerdo en que compilar es gratis, ¡las distracciones son costosas! Pero por lo demás, buena respuesta, gracias :)
CaptainCodeman
Tal vez debería haber hecho el "if" y el "iff" en negrita y cursiva ... Creo que, dependiendo del proyecto, el compilador y el entorno, puede ser bastante cercano a una acción gratuita. Si tiene una segunda ventana o pantalla para la salida del compilador, puede compilar casi tan a menudo como se detiene para respirar. Si usted fuera realmente duro (no lo soy), ni siquiera necesitaría apartar la vista de su código, siempre que el compilador produjera suficientes errores verbosos para registrarse en su visión periférica. Nuevamente, esto es si la compilación es razonablemente rápida, de lo contrario, ver arriba.
DeveloperInDevelopment
2
I hit ctrl-S about once every 30 seconds. Probablemente ahorre el doble de veces jajaja. Es una muy mala costumbre. Algunas veces guardaré en el medio de una línea de código y luego guardaré nuevamente al final. Cada vez que me detengo a pensar por un segundo y no escribo, guardo.
Cruncher
21

Hay méritos para compilar sobre la marcha. Pero estoy muy de acuerdo en que permanecer en la tarea es una buena estrategia de codificación.

El beneficio más significativo de la compilación incremental es la mentalidad que muchos obtienen si esperan hasta el final para compilar y probar : al final nos preocupa más que el código se ejecute que cualquier otra cosa en ese momento. Decimos "Oh, solo necesito agregar este paréntesis para que el compilador deje de quejarse" o "oh solo necesito capitalizar esto" sin pensar si hay un error semántico subyacente que este error de sintaxis oculta. Realmente encuentro que los errores sintácticos a menudo se anidan en errores semánticos (lo contrario no es cierto).

Como ejemplo, digamos que cambié el significado de una variable y como resultado, cambié su nombre. El cambio de nombre genera un error de sintaxis más adelante en el código, pero si simplemente complazco al cumplidor corrigiendo el nombre, ignoro por qué se produjo ese error.

Lan
fuente
55
+1 para resaltar la conexión entre los errores semánticos y sintácticos
Doc Brown
15

Entiendo los beneficios de probar su código a medida que avanza, pero ¿por qué compilar?

Pero, ¿cómo probará su código a medida que avanza cuando no compila en consecuencia?

El caso extremo es el desarrollo basado en pruebas (TDD). Es obvio que TDD no funciona con su estrategia, ya que TDD significa ciclos extremadamente cortos de prueba de escritura, compilación (debe fallar), código de escritura, compilación nuevamente, prueba de ejecución, corrección de errores, compilación nuevamente, refactorización, compilación de nuevo, prueba de funcionamiento, y así sucesivamente ...

Entonces, no todos hacen TDD, al menos no siempre (yo también, lo admito). Con su estrategia actual, nunca tendrá la oportunidad de probar TDD. Pero incluso cuando no está haciendo TDD, en mi humilde opinión es extremadamente útil probar su código más regularmente, lo que no es posible cuando no lo compila regularmente. Y cuando su prueba falla, debe ejecutarla para depurarla (lo que puede ayudarlo a comprender por qué el algoritmo de aspecto agradable que ha escrito unos minutos antes no se comporta tan bien como pensó que debería hacerlo). Y cuanto más código escriba sin compilar, más código escribirá sin probar, por lo que es más probable que se encuentre con un caso en el que no pueda predecir que el momento de solucionar el problema es "O (1)", como tu escribiste.

Doc Brown
fuente
1
Estoy de acuerdo con usted, pero creo que hay una diferencia entre compilar un programa porque desea ejecutarlo, en comparación con compilar cuando no hay nada significativo para probar (o para corregir errores de compilación).
CaptainCodeman
@CaptainCodeman: Creo que al escribir 100 líneas de código, casi siempre debería haber muchas partes pequeñas que podrían probarse individualmente. 100 líneas de código generalmente significan entre 4 y 15 funciones (o> 20, si codifica en el estilo de Bob Martin).
Doc Brown
55
@CaptainCodeman: en TDD nunca hay "nada significativo" para probar. El ejemplo clásico es que desea escribir una nueva clase (llamémosla Foo), entonces lo primero que debe hacer es crear una prueba unitaria y escribir new Foo();que obviamente no se compilará ya que no ha escrito la definición de clase. En TDD, esa es una razón válida para ejecutar un compilador: demuestra que la prueba de la unidad está funcionando (al fallar).
slebetman
@Slebetman: gracias por ese útil comentario. Me gustaría agregar que, en mi humilde opinión, esto no está restringido a TDD. Al escribir 100 líneas de código, siempre hay algo significativo para probar entre ellas, si haces TDD o no.
Doc Brown
14

De hecho, estoy de acuerdo con usted en que los errores del compilador no deberían ser un gran problema para un desarrollador experimentado. No creo que el costo de arreglarlos aumente significativamente con el tiempo como para preocuparse. Si fuera posible posponer la reparación de todos los errores del compilador hasta justo antes de un envío, lo haría, ya que presentaría una interrupción mucho más pequeña y más consolidada.

Desafortunadamente, encontrar errores de compilación no es lo único que hacen los compiladores. A riesgo de decir lo obvio, se requiere compilar para ejecutar su programa, y ​​ejecutar su programa para encontrar todos los errores de tiempo de ejecución más complejos, sutiles e interesantes que incluso los desarrolladores experimentados crean. Y esos tipos de errores son más difíciles y, por lo tanto, más caros de arreglar cuanto más tiempo posponga la depuración, ya que pueden acumularse o enmascararse entre sí.

Sin embargo, no necesariamente marcaría a alguien en un ejercicio de entrevista por posponer la compilación hasta el final. Los ejercicios de entrevista tienden a ser muy sencillos, y los desarrolladores experimentados generalmente conocen sus límites. Cuanto más confiado esté sobre lo que escribió, más tiempo pasará entre las compilaciones. Eso es solo la naturaleza humana.

Sin embargo, para no rebajarlo, la confianza tendría que estar justificada. Si hubieras pasado 45 minutos escribiendo algo sin compilar, y luego hubieras requerido otros 45 minutos para depurarlo, habría pesado mucho contra ti.

Karl Bielefeldt
fuente
8

Lo importante sobre compilar a menudo, faltando en otras respuestas hasta donde puedo ver es esto: si compila raramente y obtiene una gran cantidad de errores del compilador, la mayoría de ellos no tienen sentido, ya que son generados por el primer error. Podría deberse a que tuvo un tipo incorrecto, un error tipográfico o un error de sintaxis simple que invalida alguna declaración.

Siempre puede arreglar el primero, volver a compilar, arreglar el siguiente, y así sucesivamente, pero con una base de código grande, esto puede ser lento. Pero si intenta examinar la larga lista de errores del compilador y detectar errores independientes, entonces pasa mucho tiempo leyendo mensajes irrelevantes o navegando por el código desde el error secundario hasta la causa real.

Otra cosa que ocurre con las compilaciones regulares es que nada le impide comenzar a compilar tan pronto como tenga escrito un bloque completo de código, que debería compilarse. Luego puede continuar escribiendo más código mientras continúa la compilación, siempre que no guarde las nuevas ediciones hasta que finalice la compilación. Por lo tanto, prácticamente no se pierde tiempo esperando la construcción. Si espera hasta haber escrito todo lo que va a escribir en ese momento, debe esperar la compilación sin nada que hacer. Esta es básicamente la versión manual de lo que los IDEs modernos pueden hacer en segundo plano automáticamente.

Hyde
fuente
Curiosamente, esta es una buena razón para compilar regularmente, incluso si la compilación es lenta . Buen punto.
sleske
3

Para un programador suficientemente experimentado, el código de compilación nunca es el cuello de botella.

Una vez que conoce un idioma lo suficientemente bien (es decir, cuando ya no tiene que pensar en la sintaxis y, en cambio, solo codifica la funcionalidad), tiende a no cometer errores sintácticos simples. Los que usted hace generalmente son errores tipográficos o errores de copiar y pegar, y se pueden limpiar en poco tiempo con solo unos pocos pasos de compilación.

Regularmente escribo código todo el día sin compilar, luego compilaré y arreglaré los errores de sintaxis y las advertencias que informa el compilador antes de comprometer mi código (con una nota que dice "¡debe probarse!" ). No tengo problemas para limpiar más de 1,000 líneas de código C o C ++ en solo unos minutos.

La depuración y prueba por otro lado es lo que lleva un tiempo. Los errores lógicos surgen por todo tipo de razones y todavía tengo que encontrarme con un compilador que me dirá acerca de la subrutina que olvidé por completo escribir, o notaré que mi árbol binario no funciona porque pegué node->leftcuando debería haberlo hecho node->right.

Si bien creo que en general no es prudente pelear con un entrevistador, diría que si crees que vale la pena defender tu estilo, deberías haber señalado que te dejaste el tiempo suficiente para depurar el código que escribiste. Eso es lo que ningún buen programador nunca descuida.

PD: si te hubiera estado observando revisar el código al leerlo, te habría contratado en el acto. Eso es lo que hace un profesional, siempre.

par
fuente
44
"Todavía tengo que encontrarme con un compilador que me diga sobre la subrutina que olvidé por completo escribir". Confío totalmente en el compilador para decirme cuándo no he completado los cambios de largo alcance. A veces incluso cambio el nombre de una variable para evitar una compilación exitosa hasta que haya verificado cada instancia de su uso y les haya dado el nuevo nombre. No entiendo cómo puedes decir que no has encontrado un compilador que no te avisará si falta algo. A menos que esté escribiendo subrutinas vacías y luego se olvide de ellas, en cuyo caso el cielo lo ayudará.
Ian Goldby
@par Gracias por tu respuesta; ¡Es bueno saber que no soy el único que codifica así!
CaptainCodeman
3
@CaptainCodeman Soy consciente de que los errores lógicos son más insidiosos que los errores del compilador. Pero fue su afirmación acerca de que un compilador no podía informarle sobre la falta de código lo que quería disputar. A menos que esté escribiendo deliberadamente código incorrecto (o incompleto) que compila ..., pero que más bien derrota el argumento de que los errores que el compilador no puede detectar son el verdadero problema de la OMI. Diablos, incluso uso el compilador para mover el cursor a la línea donde la próxima vez necesito escribir algo de código. Pero tal vez soy muy vago.
Ian Goldby
1
@IanGoldby: Te perdiste el punto por completo e incluso fui tan lejos como para decir que elegiste torcer mis palabras. El compilador no puede advertirte sobre la falta de código de la misma manera que no puedo decirte lo que comerás para el desayuno mañana. Introducir errores de sintaxis intencionalmente para que el compilador le recuerde que algo es una técnica de programación; no califica como un error o le da al compilador superpoderes psíquicos.
par
1
@par Pido disculpas por la ofensa que obviamente he causado por mi comentario, no fue intencionado y ciertamente no tuve la intención de tergiversar lo que dijiste. Ahora veo que cuando escribe código incompleto que, sin embargo, se compila, lo convierte en una práctica para asegurarse de que no se pueda olvidar agregando #warning o TODO. Esa es una técnica legítima. Lo importante, en lo que ambos estamos de acuerdo, es que el código que compila pero no funciona es mucho más peligroso que el código que no compila.
Ian Goldby
3

No, no es razonable retrasar la compilación hasta que haya hecho una cantidad suficiente de código (y una "cantidad suficiente" depende del codificador y del código que se está escribiendo).

Por ejemplo, si eres un codificador increíble que se toma su tiempo para hacerlo bien, y no estás escribiendo cantidades masivas o código complicado, compilar regularmente es un desperdicio, y probablemente también una distracción. Si no lo está, compilar cada función puede ser algo bueno. Depende de la persona.

Como contraejemplo, imagine que está escribiendo código JavaScript, no hay compilador. En cambio (dada la naturaleza de la mayoría del código JavaScript), ejecutaría el programa (o actualizaría la página) para ver los resultados de su codificación. Ahora, no puede hacer eso hasta que haya escrito el código suficiente para que tenga sentido. Como resultado, los desarrolladores de JavaScript tienden a "compilar" tan a menudo como pueden, lo cual no es necesariamente muy frecuente.

En resumen, aquí no hay una respuesta correcta: el entrevistador no está equivocado, pero usted tampoco. Haz lo que te hace productivo y olvida lo que alguien te dice que debes hacer. Hay factores mucho más importantes sobre la codificación que su tendencia a acertar F7regularmente (o no) no tiene absolutamente ninguna consecuencia.

gbjbaanb
fuente
Su segundo párrafo no está claro; es posible que desee editarlo, para que quede claro si el "codificador impresionante" debe compilar regularmente o no. (¿Agregó una "t" y cambió "no" a "no"?)
DougM
@DougM - ta mucho.
gbjbaanb
Muy a menudo, el código de secuencias de comandos se desarrolla "en vivo", es decir, se ejecuta en el entorno REPL. Por lo tanto, la "compilación" sucede todo el tiempo, la mayoría del código que se escribe en el archivo fuente también se ha ejecutado una vez. No todos escriben código de secuencia de comandos de esta manera, pero diría que cualquiera acostumbrado y aficionado a la relativa "seguridad" de los lenguajes estáticamente escritos y los errores de compilación dados por un código incorrecto, deberían funcionar en lenguajes de secuencias de comandos de esta manera.
hyde
2

Con un buen entorno de desarrollo, veo pocas razones para compilar a menos que realmente esté planeando probar el código. Las herramientas de verificación de sintaxis en segundo plano captan casi todo lo que el entrevistador parece estar hablando, aunque admito que todavía hay algunos casos (que involucran cambios que se propagan a través de los archivos) que no siempre están completamente identificados.

Dicho esto, trataré de compilar y ejecutar la unidad de código más pequeña que realmente puede producir un resultado. Hace media hora estaba creando un medio para imprimir algunos resultados de búsqueda e hice media docena de impresiones de prueba (a .pdf, no en papel) haciendo cambios en el resultado para que se vea mejor, una tasa de aproximadamente 1 compilación por 10 líneas.

Loren Pechtel
fuente
1

En mi opinión y en mi experiencia, si una pieza de código se compila o no es esencialmente aleatoria, involucra cosas como si faltan o no puntos y coma, y ​​tiene poco que ver con la corrección del programa subyacente. (Para mí, centrarse en la compilación es como ejecutar un artículo a través de un corrector ortográfico sin corregir para revisar la gramática).

Mi experiencia es muy diferente: menos del 5% de los errores de compilación que obtengo tienen que ver con la sintaxis . Conozco bien el idioma, cuando recibo errores, en su mayoría son errores de tipo, diciéndome que la semántica no es correcta.

Es por eso que estoy feliz de beneficiarme lo más rápido posible de los comentarios de mi compilador. ¿Alguna vez ha experimentado el uso de un IDE que subraya los errores de compilación en tiempo real? Tener un ciclo de retroalimentación más corto puede ser muy valioso.

Si me das un código incompleto, lo primero que haré será leerlo. Ni siquiera intentaré compilarlo hasta que sepa qué está haciendo el código y sé que el algoritmo es correcto.

Si se espera que trabaje en el código escrito por otra persona, no siempre tiene tiempo para leer todo. La buena noticia es que el código bien escrito tiene un bajo acoplamiento y debería permitirle razonar independientemente sobre la parte del código que necesita.

En esos casos, debe suponer que el código que aún no ha leído es correcto e investigar perezosamente cuando hay un problema.

"hacer que el código se compile" para una determinada longitud de código generalmente implica la fijación de un número constante de errores de compilación y lleva una cantidad de tiempo bastante constante, que debería ser el mismo si lo hace después de terminar de escribir el código o si intercala con tu tiempo de codificación.

El cambio de contexto es costoso para su cerebro, por lo tanto, corregir pequeños errores tan pronto como los escriba puede ser más eficiente.

EDITAR: También puedo hacer una analogía con el control de fuente, cuando todo un equipo está trabajando en las mismas fuentes. Compilar a medida que avanza es como hacer compromisos frecuentes, ayuda a evitar tener mucho dolor al final cuando tiene que fusionar y resolver todo.

Dices que deshabilitas cosas como líneas rojas debajo de tu texto. ¿También haces eso cuando escribes un correo electrónico o escribes un documento técnico? Luego, debe volver a leer todas las páginas en lugar de corregir los errores a medida que avanza.

Otra ventaja es que, cuando trabaje en su código, si lo mantiene compilando o casi compilando en todo momento, puede beneficiarse de muchas características IDE basadas en la semántica (cambio de nombre seguro, refactorización, búsqueda de usos de un símbolo ...) .

Si desea comprender mejor cómo ayudan estas funciones, puede intentar habilitarlas y practicar, para experimentar sus beneficios. También podría intentar programar algunos pares con cualquiera que esté acostumbrado a ellos y ver cómo se benefician de ellos.

Eldritch Conundrum
fuente
1
Por lo general, apago las molestas "características" del compilador, como el formateo automático, dibujar líneas rojas debajo de su texto, etc., ya que encuentro que soy más productivo sin estas características simplificadas.
CaptainCodeman
1

Pensé un poco más sobre esto, porque sentí que hay algo muy, muy mal con el entrevistador y no pude señalar exactamente qué es. Aquí está el problema: para cualquier código que he escrito en los últimos veinte años, la cantidad de tiempo necesaria para convertir un algoritmo viable en código que compila ha sido mínimo. Cualquier ganancia en eficiencia en esa área tiene tan poco impacto en el tiempo total de desarrollo que es totalmente insignificante, y un entrevistador que rechaza a un candidato por ineficiencias percibidas en esa área no tiene idea de lo que hace un buen desarrollador.

Se debe dedicar la mayor parte del tiempo a recopilar información sobre lo que se supone que debe hacer el código, a recopilar información y especificaciones sobre servicios externos que deban usarse, crear un diseño global que conduzca a un código correcto y mantenible en lugar de piratear código y encontrar algoritmos eso conducirá a un código de trabajo en lugar de un código que se remende hasta que funcione (código que obviamente no tiene errores versus código que no tiene errores obvios).

Luego, pasa una pequeña cantidad de tiempo escribiendo código que compila.

Luego viene una mayor cantidad de tiempo invertido para asegurarse de que el código funcione y para asegurarnos de que sepamos que el código funciona y seguirá funcionando. Lo cual se hace escribiendo pruebas unitarias, recorriendo el código y, en gran medida, teniendo un código bien diseñado en primer lugar.

Este entrevistador se concentró en algo que está cubierto por diez palabras en mi respuesta. Que representan el 10 por ciento o menos del tiempo de trabajo real. Y tiene una influencia casi nula en la capacidad de ese desarrollador para producir código confiable y funcional.

gnasher729
fuente
Eso tiene mucho sentido. En mi opinión, un buen desarrollador debería ser capaz de escribir código en papel todo el día y, al final del día, escribirlo.
CaptainCodeman
1

La ventaja de "compilar a medida que avanza" es que recibe comentarios constantes y no tendrá la oportunidad de equivocarse mucho antes de ser empujado en la dirección correcta. Para un programador competente como usted, eso no es una gran consideración, pero para muchos otros sí lo es. Dicho de otra manera, "compilar a medida que avanza" es una forma de "minimizar la pérdida máxima", a pesar de que hay algunas posibles pérdidas de eficiencia en su caso.

En la actualidad, las empresas no solo están interesadas en un producto terminado. Quieren saber que estuvo "bajo control" todo el tiempo. Para ellos, "llegar allí es la mitad de la diversión".

Tom Au
fuente
Esto no parece ofrecer nada sustancial sobre lo publicado en las 16 respuestas anteriores
mosquito
2
Gracias, pero ¿de qué tipo de pérdida estamos hablando? Seguramente, a menos que haya hecho algo drástico como escribir accidentalmente en el idioma incorrecto, nunca tendrá que volver a escribir ningún código simplemente por errores de compilación.
CaptainCodeman
@CaptainCodeman: Hace que las empresas se sientan mejor y es una forma de "seguro". Eso es algo que cuesta dinero, pero hace que la mayoría de las personas (incluidos los gerentes) "duerman mejor por la noche".
Tom Au
@gnat: El punto que estaba tratando de aclarar era que la mayoría de los beneficios eran beneficios de nivel "corporativo", y es algo que el programador debería hacer porque el jefe se lo dijo, no porque el programador piense que está bien o mal.
Tom Au
Ya se han hecho puntos a favor del "ciclo de retroalimentación más corto" y se han explicado bien en la primera respuesta aquí; Sinceramente, no veo cómo el relleno al descubierto tratando de adivinar "las empresas en estos días", añade algo que merece más de lo que ya se dijo
mosquito
1

Las otras respuestas aquí montan una buena defensa para compilar con frecuencia en el trabajo , pero dado que su pregunta se centra en las entrevistas , me gustaría abordar ese ángulo.

En mis entrevistas, hago exactamente lo contrario: los candidatos no pueden usar un compilador. Escriben programas cortos en la pizarra y luego los discutimos. He descubierto que muchos desarrolladores usan el compilador (o intérprete) como una muleta, y eso es una pérdida de tiempo mucho mayor que compilar con poca frecuencia. Si te estoy ofreciendo mucho dinero y ni siquiera puedes escribir FizzBuzz correctamente sin un compilador, entonces nunca lo cortarás a largo plazo, trabajando en problemas que son 100 veces más difíciles que los ejercicios de juguete en la entrevista Y, sin embargo, estos simples ejercicios eliminan a más candidatos que cualquier otra parte de la entrevista.

El objetivo de una entrevista es evaluar el ajuste mutuo del candidato y el negocio. Una buena pregunta de entrevista debe indicar los objetivos de la pregunta y cómo se evaluará al entrevistado. Hacer una pregunta capciosa al entrevistado y luego penalizarlo por no saber la respuesta oculta no ayuda al entrevistador o al entrevistado. Desafortunadamente, la mayoría de los programadores, incluso los de mayor edad, no están capacitados para entrevistar a otros programadores, por lo que solo confían en clichés y hacen el mismo tipo de preguntas que se les hizo cuando entrevistaron, sin pensar mucho si estas son técnicas efectivas para evaluar candidatos o no.

No estoy afirmando que mi enfoque sea el "único camino verdadero", pero me ha servido muy bien. Al igual que muchas metodologías de software que comienzan con una letra mayúscula, hay un número igual de "mandatos" para las entrevistas. Todos son literas. Debe hacer lo que funcione para usted y su negocio.

Mark E. Haase
fuente
0

En proyectos más grandes, con varias subrutinas, desea probar estas partes, antes de usarlas en el esquema más grande, ya que es mucho más fácil depurar si sabe que ciertas partes ya funcionan.

Para probar estas piezas más pequeñas, necesita compilar.

Puede ser que el entrevistador confunda esta situación con un pequeño programa que no está diseñado de esta manera.

Por Alexandersson
fuente
0

Con respecto a la segunda entrevista, un beneficio de la compilación es que puede observar, en solo unos segundos, lo que los programas hacen (o no). A partir de ahí, es más fácil leer el código y centrar sus esfuerzos en las partes relevantes. Quizás esto es lo que el entrevistador esperaba.

Leer una base de código desconocida como esta de principio a fin puede ser bastante improductivo (no eres un compilador), mientras que compilar / ejecutar la aplicación rápidamente te dará una visión más amplia.

Laurent
fuente
esto no parece ofrecer nada sustancial con respecto a lo que se ha escrito en anteriores 15 respuestas
mosquito