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

  

¿Existe realmente un beneficio para compilar a medida que avanza?

Hay. Le proporciona un ciclo de retroalimentación más corto, lo cual, en general, cuando se diseña (IU, software de escritura, diseño visual, etc.) es bueno.

Un breve bucle de comentarios significa que puedes corregir rápidamente los errores antes de que sean más caros de reparar.

Para tomar prestado tu ejemplo, di que estabas codificando en un lenguaje similar a C y olvidaste } en algún lugar en medio del programa.

Si compila justo después de terminar de escribir la declaración, puede estar bastante seguro de que acaba de presentar el error de compilación y puede corregirlo allí, 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 que se encuentra el } y asegurándose de que, una vez que haya localizado el error, la solución es de hecho lo que se pretendía. Esto tendría lugar un tiempo después de que dejes ese bit de código. No sería tan claro como en el momento en que lo escribiste.

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

Compilar es una forma de prueba, especialmente en idiomas que hacen uso extensivo de tipos como Haskell o ML . En otros idiomas, es una exploración sintáctica que le dice poco.

Habiendo dicho eso, "compilar sobre la marcha" me parece un hábito muy situacional. Igualmente, puede ser menospreciado por estar "nervioso" por compilar con más frecuencia que los prejuicios personales del entrevistador. Suena como nitpicking; a nadie le gusta admitir que un entrevistado ha aprobado la prueba; inclina las escalas de la negociación salarial.

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

Compile cuando sienta que ha realizado una unidad conceptual completa en su cabeza y está listo para validarla. Una vez por minuto o una vez por semana, según el flujo de trabajo.

  

Así que mi pregunta es esta: ¿hay algo que no pude ver?

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

La compilación de 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 el forlab blablabla, y el algoritmo complejo produce el valor correcto en el retorno ") a un problema de compilación que no tiene ninguna relación 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 cambio 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 escribió es lo que escribió en una hora. Sin embargo, es un gran problema cuando se trabaja en una base de código existente, con múltiples interdependencias (y muchas veces no documentadas).

  

¿Existe realmente un beneficio para 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 hace que se sienta menos cansado (y menos propenso a cometer errores) y aumente la calidad de su producción (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). / p>

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

  

¿O es este un mito propagado por la comunidad de software que debe compilar su código con frecuencia?

También se propaga por la comunidad de software, pero tiene buenas razones detrás.

  

Según tengo entendido, es un argumento no válido, porque "hacer que el código se compile" para una longitud dada de código generalmente implica corregir un número constante de errores de compilación y toma una cantidad de tiempo bastante constante

Me parece que tiene poca (o ninguna) experiencia, en el mantenimiento de bases de código heredadas de medianas a grandes (cientos o miles de archivos de origen). Aquí es donde esta actitud (es decir, "compilar a medida que avanzas") te ayudará más, y aquí es donde formas este tipo de hábito.

Me imagino que las personas que te entrevistaron llegaron a una conclusión similar ("tienes poca o ninguna experiencia en grandes bases de código").

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

Pero obviamente hay otro lado de esto. Algunos proyectos llevan una edad para compilar. 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 normalmente 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 perezoso .

El compilador no puede ayudarlo con los errores lógicos o semánticos, y los errores de sintaxis no son tan difíciles de evitar, por lo que vale la pena gastar la mitad de la compilación del día. Por supuesto, harás errores tipográficos ocasionales, pero asumiré que puedes tanto teclear como 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 más volverá a soltar una llave, un corchete o un punto y coma. Requiere 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 plano, y compilarlo por primera vez mejor que nueve veces en diez. Claro, podría compilar más a menudo, pero no puedo recordar la última vez que tuve un error que hubiera resultado más fácil de corregir como resultado.

Si no eres un fanático de la recompilació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 "unidad   Las pruebas "me atraen solo en raras ocasiones, cuando me siento a mi manera de una manera totalmente   entorno desconocido y necesita comentarios sobre lo que funciona y lo que   no lo hace De lo contrario, se pierde mucho tiempo en actividades que simplemente   nunca es necesario 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 lo harías? En casa, en proyectos personales, presiono ctrl-S aproximadamente una vez cada 30 segundos y el atajo de "compilación" con la misma frecuencia, en un IDE que ejecuta constantemente el código a través del extremo frontal del compilador para proporcionar resaltado de errores en tiempo real. ¿Por qué dejar pasar un almuerzo gratis?

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 importante de la compilación incremental es la mentalidad que muchos obtienen si esperan el final para compilar y probar : al final, nos preocupa más que el código se ejecute más que cualquier otra cosa. otra cosa en ese punto. Decimos "Oh, solo necesitamos agregar este corchete para que el compilador deje de quejarse" o "oh, solo necesito poner mayúsculas en esto" sin pensar si hay un error semántico subyacente que este error de sintaxis oculta. Realmente encuentro errores sintácticos que 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 le complacemos al complaciente corrigiendo el nombre, ignoré por qué que el error entró en existencia.

En realidad estoy de acuerdo contigo 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 lo suficiente con el tiempo para preocuparse. Si fuera posible posponer la corrección de todos los errores del compilador hasta justo antes de un impulso, lo haría, ya que presentaría una interrupción mucho más pequeña y más consolidada.

Desafortunadamente, encontrar errores en el compilador no es lo único que hacen los compiladores. A riesgo de manifestar lo obvio, se requiere la compilación para ejecutar su programa, y la ejecución de su programa es necesaria 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 costosos de solucionar cuanto más tiempo posponga la depuración de ellos, 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 suelen conocer sus límites. Cuanto más seguro tengas de lo que escribiste, más tiempo pasarás entre compilaciones. Eso es solo la naturaleza humana.

Sin embargo, para no marcarte por ello, la confianza debería estar justificada. Si hubiera pasado 45 minutos escribiendo algo sin compilar, luego requirió otros 45 minutos para depurarlo, habría pesado mucho contra usted.

  

Comprendo 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 desarrollo dirigido por pruebas (TDD). Es obvio que TDD no funciona con su estrategia, ya que TDD significa ciclos extremadamente cortos de prueba de escritura, compilación (debería fallar), código de escritura, compilación nuevamente, prueba de ejecución, correcciones de errores, compilación nuevamente, refactorización, compilación -de nuevo, prueba de ejecución, y así sucesivamente ...

Así que 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, es de gran ayuda, en mi humilde opinión, probar su código más regularmente, lo cual no es posible cuando no lo compila regularmente. Y cuando su prueba falla, se está ejecutando para depurarla (lo que puede ayudarlo a comprender por qué el buen algoritmo que ha escrito algunos minutos antes no se comporta tan bien como pensaba que debería hacerlo). Y mientras más código escriba sin compilar, más código escribirá sin probar, por lo que es más probable que ocurra que se encuentre con un caso en el que no pueda predecir que el momento para solucionar el problema es " O (1) ", como escribiste.

La única cosa importante acerca de la compilación frecuente, que falta en otras respuestas, por lo que puedo ver, es la siguiente: si compilas rara vez y obtienes una gran cantidad de errores de compilación, la mayoría de ellos no tienen sentido, ya que son generados por el primero. error. Puede deberse a un error de tipo, error tipográfico o sintaxis simple que hace que alguna declaración sea inválida.

Siempre se 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 hojear la larga lista de errores de compilación y los errores de localización que son independientes, entonces pasa mucho tiempo leyendo mensajes irrelevantes, o navegando el código desde el punto de error secundario hasta la causa real.

Otra cosa que sucede con las compilaciones regulares es que nada le impide comenzar a compilar tan pronto como haya escrito un bloque completo de código, que debería compilar. Luego puede continuar escribiendo más código mientras continúa la compilación, siempre y cuando no guarde las nuevas ediciones hasta que la compilación termine. Así que prácticamente no se pierde tiempo en esperar a construir. Si espera hasta que haya escrito todo lo que va a escribir en ese momento, tendrá que esperar a la compilación sin nada que hacer. Esta es básicamente la versión manual de lo que los IDE modernos pueden hacer en segundo plano automáticamente.

Para un programador con suficiente experiencia, 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 su lugar, simplemente codifique la funcionalidad), tiende a no cometer simples errores sintácticos. Aquellos que hacen son generalmente errores tipográficos o de copiar y pegar, y se pueden limpiar en poco tiempo con solo unos pocos pases de compilación.

Escribo el código regularmente todo el día sin compilar, luego compilaré y corregiré qué errores de sintaxis y advertencias informa el compilador antes de confirmar mi código (con una nota que dice "¡se debe probar!" ). 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 la 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 diga acerca de la subrutina que olvidé escribir, o me daré cuenta de que mi árbol binario no funciona porque pegué node->left cuando debería haberlo hecho. sido node->right .

Aunque creo que generalmente no es prudente pelear con un entrevistador, yo diría que si consideras que vale la pena defender tu estilo, deberías haber señalado que te dejaste el tiempo suficiente para depurar el código que habia escrito Eso es lo que ningún buen programador descuida.

p.s. - Si te hubiera estado viendo revisar el código al leerlo, te habría contratado en el acto. Eso es lo que hace un profesional, cada vez.

No, no es irrazonable suspender la compilación hasta que hayas 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ódigos complicados, entonces compilar con regularidad es un desperdicio, y probablemente también una distracción. Si no lo eres, entonces compilar cada función puede ser algo bueno. Depende de la persona.

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

En resumen, no hay una respuesta correcta aquí: 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 golpear F7 con regularidad (o no) no tiene ninguna consecuencia.

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 de lo que parece estar hablando el entrevistador, aunque admito que todavía hay algunos casos (que involucran cambios que se propagan a través de archivos) que no siempre están completamente identificados.

Dicho esto, intentaré compilar y ejecutar prácticamente la unidad más pequeña de código 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 (en formato .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.

  

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

Mi experiencia es muy diferente: menos del 5% de los errores de compilación que recibo son sobre la sintaxis . Conozco bien el idioma, cuando recibo errores, en su mayoría son errores de tipo que me dicen que la semántica no es correcta.

Por eso me complace beneficiarme lo más rápido posible de los comentarios de mi compilador. ¿Alguna vez has experimentado con 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 fragmento de 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 un 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 acoplamiento bajo y debería permitirle razonar de manera independiente solo sobre la parte del código que necesita.

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

  

"hacer que el código se compile" para una longitud de código dada generalmente implica corregir un número constante de errores de compilación y toma una cantidad de tiempo bastante constante, que debería ser igual si lo haces después de terminar de escribir el código, o Si lo intercalas con tu tiempo de codificación.

El cambio de contexto es costoso para tu cerebro, por lo tanto, corregir pequeños errores tan pronto como los escribas 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. La compilación a medida que avanza es como hacer confirmaciones frecuentes, ayuda a evitar tener mucho dolor al final cuando tiene que fusionar y resolver todo.

Usted dice que deshabilita cosas como líneas rojas debajo de su texto. ¿También hace eso cuando escribe un correo electrónico o escribe un documento técnico? Luego tienes que volver a revisar todas las páginas en lugar de corregir errores a medida que avanzas.

Otra ventaja es que, al trabajar en su código, si lo mantiene compilando o casi compilando en todo momento, puede beneficiarse de una gran cantidad de funciones IDE basadas en semántica (cambio de nombre, refactorización, búsqueda de usos de un símbolo). ..).

Si desea tener una mejor comprensión de cómo ayudan estas características, puede intentar habilitarlas y practicar, para experimentar sus beneficios. También puedes intentar programar un par con cualquiera que esté acostumbrado a ellos, y ver cómo ellos se benefician de ellos.

Pensé un poco más en esto, porque sentí que hay algo muy, muy mal con el entrevistador y no podía señalar exactamente qué es. Aquí está el problema: para cualquier código que haya escrito en los últimos veinte años, la cantidad de tiempo necesario para convertir un algoritmo viable en código que compila ha sido mínima. 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 las ineficiencias percibidas en esa área no tiene idea de lo que hace a un buen desarrollador.

La mayor parte del tiempo debe dedicarse a recopilar información sobre lo que se supone que debe hacer el código, recopilar información y especificaciones sobre los servicios externos que deben utilizarse, crear un diseño global que conduzca a un código correcto y mantenible en lugar de un código pirateado. y encontrar algoritmos que conduzcan a un código de trabajo en lugar de un código que esté parcheado hasta que funcione (código que obviamente no tiene errores en comparación con un código que no tiene errores obvios).

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

Luego viene una mayor cantidad de tiempo dedicado a asegurarse de que el código funciona, y de asegurarnos de que sabemos que el código funciona y seguirá funcionando. Lo que 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 sobre la capacidad de ese desarrollador para producir código confiable y de trabajo.

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

En mis entrevistas, hago exactamente lo contrario: los candidatos no pueden usar un compilador. Escriben programas cortos en la pizarra y luego los discutimos. Descubrí 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 la entrevista debe indicar los objetivos de la pregunta y cómo se evaluará al entrevistado. Hacer una pregunta engañosa sobre el 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 los clichés y les hacen el mismo tipo de preguntas que cuando se los entrevistó, sin pensar mucho en 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. Como tantas metodologías de software que comienzan con una letra mayúscula, hay un número igual de "mandatos" para la entrevista. Todos son literas. Debe hacer lo que funcione para usted y su empresa.

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 de depurar si sabe que ciertas partes ya funcionan.

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

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

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

La lectura de una base de código desconocida como esta desde el principio hasta el final puede ser bastante improductiva (no eres un compilador), mientras que compilar / ejecutar la aplicación te dará una imagen más grande rápidamente.

La ventaja de "compilar sobre la marcha" es que recibes comentarios constantes y no tendrás la oportunidad de equivocarte 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 lo es. Dicho de otra manera, "compilar a medida que avanza" es una forma de "minimizar la pérdida máxima", aunque en su caso haya algunas posibles pérdidas de eficiencia.

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