Existe algum benefício em compilar seu código à medida que você avança?

Is there actually a benefit to compiling as you go along?

Existe. Ele oferece um ciclo de feedback mais curto - que, em geral, ao projetar (interface do usuário, software de gravação, design visual, etc.) é uma coisa boa.

Um ciclo de feedback curto significa que você pode corrigir os erros rapidamente no início, antes que eles se tornem mais caros para corrigir.

Para pegar seu exemplo, diga que você estava codificando em uma linguagem semelhante a C e esqueceu um } em algum lugar no meio do programa.

Se você compilar logo após terminar de escrever a declaração, pode ter certeza de que acaba de apresentar o erro de compilação e pode corrigi-lo lá e depois, em segundos.

Se você não tiver, no entanto, você teria que gastar um bom tempo lendo o código, procurando a posição exata que o } é e certificando-se, depois de ter localizado o erro que a correção é na verdade, o que se pretendia. Isso ocorreria um pouco depois que você deixasse aquele pedaço de código. Não seria tão claro como no momento em que você o escreveu.

Agora, sim, o resultado final é o mesmo, mas você gastou muito tempo em questões sintáticas com as quais o compilador está presente para ajudá-lo - uma quantidade de tempo que pode ser significativamente mais curto se você compilou como você foi junto.

Compilar é uma forma de teste, especialmente em linguagens que fazem uso extensivo de tipos como Haskell ou ML . Em outras línguas, é uma varredura sintática que diz pouco.

Dito isto, "compilar como você vai" parece-me um hábito muito situacional. Você poderia igualmente ser marcado para ser "inquieto" por compilar com mais freqüência do que o preconceito pessoal do entrevistador. Soa como nitpicking; ninguém gosta de admitir que um entrevistado tenha aceitado o teste; ele aponta as escalas da negociação salarial.

Nem todos os sistemas de compilação são rápidos. Eu trabalhei em um projeto (C ++) onde Make gastaria 30 segundos apenas stat 'configurando tudo para determinar se precisava ser compilado ou não, e a maioria dos arquivos levaria alguns minutos para compilar se você tivesse feito alterar. Nós estávamos relutantes em fazer isso com mais freqüência do que a cada 10-15 minutos. Alguém, sem dúvida, fornecerá uma anedota de quando for necessário pegar seu baralho e levá-lo para um prédio diferente ...

Compile quando você sentir que fez uma unidade conceitual completa em sua cabeça e esteja pronto para validá-la. Uma vez por minuto ou uma vez por semana, dependendo do fluxo de trabalho.

So my question is this: Is there something I missed?

Sim: sua mente não é um compilador. Enquanto um compilador pode fazer n mudanças de contexto por segundo, sua mente não pode. O número de mudanças de contexto que sua mente pode fazer em um dia depende de vários fatores como experiência / familiaridade com código base, quão mentalmente você está no código, quão limpo é o código, quão complexo é o problema que você está enfrentando, como você está cansado, se você é freqüentemente interrompido ou em um ambiente barulhento e assim por diante.

Compilar uma base de código (tudo ao mesmo tempo), pela primeira vez (pense em "projeto com 20 arquivos") irá forçá-lo a mudar o contexto do que você está pensando (ex: "este valor é definido para 5 aqui , em seguida, no loop loop blablabla, e o algoritmo complexo produz o valor correto no retorno ") para um problema de compilação que é completamente não relacionado ao que você está pensando (nomes diferentes de arquivo / módulo / função / pré-condições / sintaxe / variável , pré-condições, etc.).

Quanto mais código você compilar de uma vez, mais mudança de contexto sua mente precisa fazer. Isso não é um problema para uma pequena base de código, quando todo o código que você escreveu é o que você escreveu em uma hora. No entanto, é um grande problema quando se trabalha em uma base de código existente, com múltiplas (e muitas vezes não documentadas) interdependências.

Is there actually a benefit to compiling as you go along?

Você minimiza as mudanças de contexto que sua mente precisa fazer, permitindo que você se concentre mais no impacto e nos efeitos colaterais das alterações feitas. Isso também deixa você menos cansado (e menos propenso a erros) e aumenta a qualidade de sua saída (ou seja, você pode garantir efeitos colaterais minimizados mais facilmente quando você altera e compila um arquivo de cada vez, do que quando compila e altera dez). / p>

Se você compilar em iterações muito curtas (isto supõe que o processo de compilação é otimizado para demorar pouco tempo) é possível corrigir erros de compilação sem sair da "zona".

Or is this some sort of myth propagated by the software community that you must compile your code frequently?

Também é propagado pela comunidade de software, mas tem boas razões por trás disso.

In my understanding that's an invalid argument, because "getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time

Parece-me que você tem pouca (ou nenhuma) experiência na manutenção de bases de código herdadas de médio a grande porte (centenas ou milhares de arquivos de origem). É aí que essa atitude (ou seja, "compilar como você vai") vai ajudar mais, e é aí que você forma esse tipo de hábito.

Eu imagino que as pessoas que o visualizaram fizeram uma conclusão semelhante ("você tem pouca ou nenhuma experiência em grandes bases de código").

Eu acho que há mais do que um pequeno esnobismo profissional aqui. A implicação parece ser "se você nunca teve a necessidade de compilar regularmente, então você nunca trabalhou com algo tão complicado - obtenha mais experiência e volte quando tiver aprendido a trabalhar exatamente da maneira que fazemos."

Mas obviamente há outro lado nisso. Alguns projetos levam uma idade para compilar. Eu trabalhei com estruturas que levam 30 minutos ou mais para compilar depois de pequenas edições. O céu te ajuda se você precisar editar um arquivo de cabeçalho. Recompilações completas são tipicamente feitas durante a noite, e se você está confiando no compilador para pegar seus erros, ainda existem erros raros que não serão detectados durante uma compilação parcial. Você simplesmente não re-compila a cada 5 minutos sob essas condições - a menos que esteja com preguiça .

O compilador não pode ajudá-lo com erros lógicos ou semânticos e os erros de sintaxe não são tão difíceis de evitar que gastar a metade da compilação do dia se torna valioso. Naturalmente, você fará o erro ocasional, mas eu vou assumir que você pode digitar e ler. Se você tiver a liberdade de escolher, use um estilo de codificação que faça bom uso do layout para destacar visualmente os erros e nunca mais deixe cair um suporte, suporte ou ponto-e-vírgula novamente. É preciso um pouco de prática e um pouco mais de disciplina do que a maioria está acostumada, mas é possível. Eu posso escrever código por algumas horas por vez, em um editor de texto simples, e compilá-lo pela primeira vez melhor do que nove em cada dez vezes. Claro, eu poderia compilar com mais frequência, mas não me lembro da última vez que tive um erro que teria sido mais fácil de corrigir como resultado.

Se você não é fã de recompilação constante, você está em boa companhia. Aqui está Donald Knuth:

As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about.

Tudo o que foi dito ... se você está trabalhando em um contexto onde a compilação é uma ação livre, por que você não faria isso? Em casa, em projetos pessoais, acertei o ctrl-S uma vez a cada 30 segundos e o atalho "compilar" quase sempre, em um IDE que constantemente executa o código através do front end do compilador para fornecer realce de erro em tempo real. Por que deixar um almoço grátis?

Existem méritos para compilar à medida que você for. Mas eu concordo muito que permanecer na tarefa é uma boa estratégia de codificação.

O benefício mais significativo para a compilação incremental é a mentalidade em que muitos entram quando esperam pelo final para compilar e testar : estamos mais preocupados com o fim de fazer o código rodar mais nesse ponto. Dizemos "Oh, só precisamos adicionar este colchete para que o compilador pare de reclamar" ou "oh apenas precisa capitalizar isso" sem pensar se há um erro semântico subjacente que esse erro de sintaxe oculta. Eu realmente acho que erros sintáticos frequentemente se aninham em erros semânticos (o contrário não é verdade).

Por exemplo, digamos que eu mudei o significado de uma variável e, como resultado, mudei seu nome. A mudança de nome gera um erro de sintaxe mais tarde no código, mas se eu apenas agradar o complier corrigindo o nome, ignorei por que esse erro passou a existir.

Eu realmente concordo com você que os erros do compilador não devem ser um grande problema para um desenvolvedor experiente. Eu não acho que o custo de consertá-los aumente o suficiente com o tempo para se preocupar. Se fosse possível adiar a correção de todos os erros do compilador até um pouco antes de um push, eu o faria, pois apresentaria uma interrupção muito menor e mais consolidada.

Infelizmente, encontrar erros de compilador não é a única coisa que os compiladores fazem. Correndo o risco de declarar o óbvio, a compilação é necessária para executar o seu programa, e executar o seu programa é necessário para encontrar todos os erros de tempo de execução mais complexos, sutis e interessantes que até os desenvolvedores experientes criaram. E esses tipos de bugs são mais difíceis e, portanto, mais caros de corrigir, quanto mais tempo você adiar a depuração, porque eles podem construir ou mascarar uns aos outros.

No entanto, eu não necessariamente marcaria alguém em um exercício de entrevista para adiar a compilação até o final. Exercícios de entrevista tendem a ser muito diretos, e os desenvolvedores experientes geralmente conhecem seus limites. Quanto mais confiante você estiver sobre o que você escreveu, mais tempo você passará entre as compilações. Isso é apenas a natureza humana.

A fim de não marcá-lo para baixo, a confiança teria que ser justificada, no entanto. Se você tivesse passado 45 minutos escrevendo algo sem compilar, então precisaria de mais 45 minutos para depurá-lo, eu teria pesado muito com você.

I understand the benefits of testing your code as you go along, but why compiling?

Mas como você testará seu código conforme avança quando não compila adequadamente?

O caso extremo é o desenvolvimento orientado a testes (TDD). É óbvio que o TDD não funciona com a sua estratégia, já que TDD significa ciclos extremamente curtos de teste de escrita, compilação (falha), código de escrita, compilação de novo, teste de execução, correção de bugs, compilação de novo, refatoração, compilação novamente, corra-teste e assim por diante ...

Então nem todo mundo faz TDD, pelo menos nem sempre (eu também, eu admito). Com a sua estratégia atual, você nunca terá a chance de experimentar o TDD. Mas mesmo quando você não está fazendo TDD, é extremamente útil testar seu código mais regularmente - o que não é possível quando você não compila regularmente. E quando o seu teste falha, você tem que correr para depurá-lo (o que pode ajudá-lo a entender por que o algoritmo bonito que você escreveu alguns minutos antes não se comporta tão bem como você acha que deveria ser feito). E quanto mais código você escreve sem compilar, mais código você escreve sem testar, então o mais provável é que você encontre um caso em que você não pode prever que o tempo para corrigir o problema é " O (1) ", como você escreveu.

A coisa mais importante sobre compilar frequentemente, faltando em outras respostas até onde eu posso ver é esta: se você compila raramente e obtém uma grande quantidade de erros do compilador, a maioria deles não tem sentido, porque eles são gerados pelo primeiro. erro. Poderia ser porque você tinha erro de digitação ou erro de digitação ou erro de sintaxe simples que torna inválida alguma declaração.

Você pode sempre consertar o primeiro, recompilar, consertar o próximo, e assim por diante, mas com base de código grande, isso pode ser lento. Mas se você tentar percorrer a longa lista de erros do compilador e detectar erros que são independentes, então você gasta muito tempo lendo mensagens irrelevantes ou navegando de um ponto de erro secundário para uma causa real.

Outra coisa que vai para compilações regulares é que nada impede que você comece a compilar assim que você tiver um bloco completo de código escrito, que deve ser compilado. Você pode continuar escrevendo mais código enquanto a compilação continua, contanto que você não salve as novas edições até que a compilação seja concluída. Então, praticamente não há tempo perdido em esperar pela construção. Se você esperar até ter escrito tudo o que vai escrever naquele momento, terá que esperar pela compilação sem nada para fazer. Esta é basicamente a versão manual do que os IDEs modernos podem fazer automaticamente em segundo plano.

Para um programador suficientemente experiente, a compilação de código nunca é o gargalo.

Uma vez que você conhece uma linguagem suficientemente bem (ou seja, quando você não precisa mais pensar sobre a sintaxe e, ao invés disso, apenas codifica para funcionalidade), você tende a não cometer erros sintáticos simples. Aqueles que você cria geralmente são erros de digitação ou erros de copiar e colar, e eles podem ser limpos em pouco tempo com apenas alguns passos de compilação.

Eu regularmente escrevo código o dia todo sem compilar, então eu vou compilar e apenas consertar quais erros de sintaxe e avisos o compilador reporta antes de eu enviar meu código (com uma nota que diz "precisa ser testada!" ). Não tenho problema em limpar mais de 1.000 linhas de código C ou C ++ em apenas alguns minutos.

Depuração e teste, por outro lado, é o que leva um tempo. Erros lógicos surgem por todos os tipos de razões e eu ainda não encontrei um compilador que me falará sobre a sub-rotina que eu esqueci completamente de escrever, ou notarei que minha árvore binária não funciona porque colei node->left quando deveria ter foi node->right .

Embora eu ache que geralmente é insensato lutar com um entrevistador, eu diria que se você acha que vale a pena defender seu estilo, você deve ter apontado que você deixou tempo suficiente para depurar o código que você tinha escrito. Essa é a coisa que nenhum bom programador negligencia.

p.s. - Se eu estivesse assistindo você revisar o código lendo-o, eu teria contratado você no local. Isso é o que um profissional faz toda vez.

Não, não é despropositado adiar a compilação até que você tenha feito uma quantidade suficiente de código (e uma 'quantidade suficiente' depende do codificador e do código sendo escrito).

Por exemplo, se você é um programador incrível que leva tempo para acertar, e não está escrevendo grandes quantidades ou códigos complicados, então compilar regularmente é um desperdício, e provavelmente uma distração também. Se você não for, então compilar cada função pode ser uma coisa boa. Depende da pessoa.

Como contra-exemplo, imagine que você esteja escrevendo código JavaScript - não há compilador. Em vez disso (dada a natureza da maioria do código JavaScript), você executaria o programa (ou atualizaria a página) para ver os resultados da sua codificação. Agora, você não pode fazer isso até que esteja escrito código suficiente para fazer sentido. Como resultado, os desenvolvedores de JavaScript tendem a "compilar" com a maior frequência possível, o que não é necessariamente muito frequente.

Em suma, não há resposta correta aqui - o entrevistador não está errado, mas você também não está. Faça o que te faz produtivo e esqueça o que alguém lhe diz que você deveria fazer. Existem fatores muito mais importantes sobre codificação do que sua tendência a acertar F7 regularmente (ou não) de absolutamente nenhuma consequência.

Com um bom ambiente de desenvolvimento, vejo poucos motivos para compilar a menos que você esteja realmente planejando testar o código. As ferramentas de verificação de sintaxe em segundo plano captam quase tudo o que o entrevistador parece estar falando, embora eu admita que ainda existem alguns casos (envolvendo mudanças que se propagam pelos arquivos) que nem sempre são totalmente identificados.

Dito isso, vou tentar compilar e executar praticamente a menor unidade de código que pode realmente produzir um resultado. Meia hora atrás eu estava criando um meio de imprimir alguns resultados de pesquisa e fiz meia dúzia de impressões de teste (para .pdf, não papel) fazendo alterações no resultado para torná-lo melhor - uma taxa de cerca de 1 compilação por 10 linhas.

In my opinion and in my experience, whether or not a piece of code compiles is essentially random, involving things like whether or not semicolons are missing, and has little to do with the correctness of the underlying program. (To me, focusing on compiling is like running an article through a spell-check without proofreading to check the grammar.)

Minha experiência é muito diferente: menos de 5% dos erros de compilação que recebo são sobre a sintaxe . Eu conheço bem a linguagem, quando recebo erros é principalmente erros de tipo, me dizendo que a semântica não está correta.

É por isso que estou feliz em me beneficiar o mais rápido possível do feedback do meu compilador. Você já experimentou o uso de um IDE que sublinha os erros de compilação em tempo real? Ter um feedback mais curto pode ser muito valioso.

If you give me a piece of incomplete code, the first thing I do will be to read it. I won't even try to compile it until I know what the code is doing and I know the algorithm is correct.

Se espera-se que você trabalhe no código escrito por outra pessoa, nem sempre você terá tempo para ler tudo. A boa notícia é: código bem escrito tem baixo acoplamento e deve permitir que você raciocine de forma independente sobre apenas a parte do código que você precisa.

Nesses casos, você deve assumir que o código que você ainda não leu está correto e investigar preguiçosamente quando houver um problema.

"getting code to compile" for a given length of code generally involves fixing a constant number of compile errors and takes a fairly constant amount of time, which should be the same whether you do it after you finish writing the code, or if you interleave it with your coding time.

A troca de contexto é cara para o cérebro, portanto, corrigir pequenos erros assim que você os escreve pode ser mais eficiente.

EDIT: Eu também posso fazer uma analogia com o controle de origem, quando uma equipe inteira está trabalhando nas mesmas fontes. Compilar à medida que você avança é como fazer commits frequentes, ajuda a evitar ter muita dor no final quando você tem que se fundir e resolver tudo.

Você diz que desabilita coisas como linhas vermelhas em seu texto. Você também faz isso quando digita um email ou escreve um documento técnico? Então você tem que revisar todas as páginas ao invés de consertar os erros.

Outra vantagem é que, ao trabalhar em seu código, se você o mantém compilando ou quase compilando o tempo todo, pode se beneficiar de muitos recursos IDE baseados em semântica (renomeação segura, refatoração, localização de um símbolo. ..).

Se você quiser ter uma melhor compreensão de como esses recursos ajudam, experimente capacitá-los e praticar seus benefícios. Você também pode tentar fazer algumas programações de pares com qualquer um que esteja acostumado com elas e ver como elas se beneficiam delas.

Eu pensei um pouco mais sobre isso, porque eu senti que há algo muito, muito errado com o entrevistador e não poderia exatamente indicar o que é. Aqui está o problema: Para qualquer código que eu tenha escrito nos últimos vinte anos, a quantidade de tempo necessária para transformar um algoritmo viável em código que compila foi mínimo. Qualquer ganho de eficiência nessa área tem tão pouco impacto no tempo total de desenvolvimento que é totalmente insignificante, e um entrevistador que rejeitar um candidato a percebidas ineficiências nessa área não tem idéia do que faz um bom desenvolvedor.

A maior parte do tempo deve ser gasto na coleta de informações sobre o que o código deve fazer, reunindo informações e especificações sobre serviços externos que precisam ser usados, criando um design global que levará a códigos corretos e passíveis de manutenção, e encontrar algoritmos que levarão ao código de trabalho em vez do código que é corrigido até que funcione (código que obviamente não possui erros versus código que não possui erros óbvios).

Depois vem um pequeno período de tempo escrevendo código que compila.

Em seguida, uma quantidade maior de tempo é gasta para garantir que o código funcione e para garantir que o código funcione e continue funcionando. O que é feito escrevendo testes de unidade, percorrendo o código e, em grande parte, tendo um código bem projetado em primeiro lugar.

Este entrevistador concentrou-se em algo que é coberto por dez palavras na minha resposta. Quais representam 10% ou menos do tempo real de trabalho. E tem quase zero influência na capacidade desse desenvolvedor de produzir código confiável e funcional.

As outras respostas aqui formam uma boa defesa para compilar com frequência no trabalho , mas como sua pergunta está centrada em entrevistas , eu gostaria de abordar esse ângulo de isso.

Nas minhas entrevistas, eu faço exatamente o oposto: os candidatos não podem usar um compilador. Eles escrevem programas curtos no quadro branco e depois os discutimos. Eu descobri que muitos desenvolvedores usam o compilador (ou intérprete) como uma muleta, e isso é um desperdício de tempo muito maior do que compilar muito raramente. Se eu estou te oferecendo muito dinheiro e você não pode nem mesmo escrever o FizzBuzz corretamente sem um compilador, então você nunca vai cortá-lo a longo prazo, trabalhando em problemas que são 100 vezes mais difíceis do que os exercícios de brinquedo. na entrevista. E, no entanto, esses exercícios simples eliminam mais candidatos do que qualquer outra parte da entrevista.

O objetivo de uma entrevista é avaliar o ajuste mútuo do candidato e do negócio. Uma boa entrevista deve indicar os objetivos da questão e como o entrevistado será avaliado. Colocar uma pergunta difícil no entrevistado e depois penalizá-lo por não saber a resposta oculta não ajuda o entrevistador ou o entrevistado. Infelizmente, a maioria dos programadores - mesmo os mais experientes - não são treinados para entrevistar outros programadores, então eles só confiam em clichês e fazem os mesmos tipos de perguntas que eles fizeram quando entrevistaram, sem muito se essas são técnicas eficazes para avaliar candidatos. ou não.

Eu não estou afirmando que a minha abordagem é o "único caminho verdadeiro", mas me serviu muito bem. Como muitas metodologias de software que começam com uma letra maiúscula, há um número igual de "mandatos" para entrevistas. Eles são todos belicosos. Você precisa fazer o que funciona para você e sua empresa.

Em projetos maiores, com várias sub-rotinas, você deseja testar essas partes, antes de usá-las no esquema maior, já que é mais fácil depurar se você souber que certas partes já funcionam.

Para testar essas peças menores, você precisa compilar.

Pode ser que o entrevistador confunda essa situação com um programa pequeno que não é projetado dessa maneira.

Em relação à segunda entrevista, um benefício da compilação é que você pode observar, em apenas alguns segundos, o que os programas fazem (ou não). A partir daí, é mais fácil ler o código e concentrar seus esforços nas partes relevantes. Talvez seja isso que o entrevistador estava esperando.

Ler uma base de código desconhecida como essa do começo ao fim pode ser bastante improdutivo (você não é um compilador), enquanto compilar / executar o aplicativo rapidamente lhe dará uma visão mais ampla.

A vantagem de "compilar à medida que você avança" é que você obtém feedback constante e não terá a chance de ir muito longe antes de ser empurrado na direção certa. Para um programador competente como você, isso não é uma grande consideração, mas para muitos outros é. Dito de outra forma, "compilar à medida que você avança" é uma maneira de "minimizar a perda máxima", mesmo que haja algumas perdas potenciais de eficiência no seu caso.

Atualmente, as empresas não estão interessadas apenas em um produto acabado. Eles querem saber que estava "sob controle" o tempo todo. Para eles, "chegar lá é metade da diversão".