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?
fuente
Respuestas:
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.
fuente
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.
fuente
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).
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".
También lo propaga la comunidad de software, pero tiene buenas razones para respaldarlo.
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").
fuente
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:
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?
fuente
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.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.
fuente
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.
fuente
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).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.
fuente
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.
fuente
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 hechonode->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.
fuente
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.
fuente
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.
fuente
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 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.
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.
fuente
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.
fuente
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".
fuente
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.
fuente
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.
fuente
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.
fuente