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

183

Recentemente, tive uma entrevista de emprego na qual eles me deram uma hora para escrever um código real. Não era uma quantidade enorme, provavelmente menos de 100 linhas. Após cerca de 45 minutos, compilei, executei e fiz funcionar. Eu posso ter gasto de 5 a 10 minutos trabalhando com erros de compilação e alguns pequenos erros, mas no geral foi muito tranquilo. (Aliás, recebi uma oferta deles.)

No entanto, o que me intrigou foi que, depois que eu entreguei o código completo, o entrevistador me disse que a única coisa que fiz de errado foi "não compilar à medida que avanço". Perguntei a ele qual era a diferença e ele disse "o que você faria se terminasse o código e ele não fosse compilado a tempo".

No meu entendimento, esse é um argumento inválido, porque "obter código para compilar" para um determinado comprimento de código geralmente envolve a correção de um número constante de erros de compilação e leva um tempo bastante constante, que deve ser o mesmo, se você fizer isso depois de fazer o mesmo. termine de escrever o código ou se você o intercalar com o tempo de codificação. Se alguma coisa, interromper sua codificação para procurar pontos e vírgulas ausentes provavelmente seria prejudicial à sua eficiência. Exceto em circunstâncias extremas, quando estou experimentando obscuridades em casos extremos em coisas como funções virtuais em classes derivadas, etc. parece razoável esperar que o código escrito por um desenvolvedor experiente compile, menos o erro de digitação ocasional e até se não, é '

Em outro incidente semelhante, recebi uma base de código incompleta em uma entrevista e pedi para finalizá-la e fazer as modificações necessárias para fazê-la funcionar. Comecei lendo o código existente e, depois de alguns minutos (mesmo antes de terminar de ler o código), o entrevistador me disse que isso basta. Quando perguntei a ele o que ele teria feito (ou seja, "o que eu fiz de errado"), ele me disse que começaria obtendo imediatamente o código para compilar.

Por que isso é relevante? Na minha opinião e na minha experiência, se um pedaço de código é compilado ou não é essencialmente aleatório, envolvendo coisas como falta ou não-ponto-e-vírgula e pouco tem a ver com a correção do programa subjacente. (Para mim, focar na compilação é como executar um artigo em uma verificação ortográfica sem revisão para verificar a gramática.)

Se você me der um pedaço de código incompleto, a primeira coisa que faço será lê-lo. Nem tentarei compilá-lo até saber o que o código está fazendo e o algoritmo está correto.

De qualquer forma, esses foram apenas alguns incidentes recentes, mas, em geral, ouvi muitos desenvolvedores falarem sobre a compilação de seu código à medida que avançam, e ainda assim ninguém foi capaz de me dizer o benefício disso. Entendo os benefícios de testar seu código à medida que avança, mas por que compilar?

Então, minha pergunta é a seguinte: há algo que eu perdi? Existe realmente um benefício em compilar à medida que avança? Ou isso é algum tipo de mito propagado pela comunidade de software de que você deve compilar seu código com frequência?

CaptainCodeman
fonte
54
Ou isso, ou que meus hábitos estão sendo chamados de maus hábitos por pessoas que têm hábitos diferentes.
CaptainCodeman
9
@DocBrown A comparação é válida se o objetivo final estiver com um produto correto. Um programa que "executa" não é melhor do que um programa que executa incorretamente. Você não pode esperar que a compilação verifique seu código mais do que você pode esperar de uma verificação ortográfica para corrigir seus erros gramaticais.
CaptainCodeman
7
Se a compilação atrapalha o seu fluxo de trabalho é muito subjetiva e depende da linguagem, ambiente de construção, tamanho / complexidade do projeto etc. É mais provável que a OMI seja um problema em grandes projetos herdados.
Pjc50
64
Concordo plenamente com o OP. Não consigo entender como alguém pode julgar seus hábitos de trabalho, por exemplo, quando ele usa para iniciar o compilador. A única coisa que conta é a produção dos esforços. Está correto? É sustentável? Ele é executado no prazo esperado? Quanto tempo levou para implementá-lo? Essas são perguntas interessantes. Tudo o resto é BS arbitrário. Se o entrevistado escreve um código perfeito de 2 horas que é compilado na primeira tentativa, onde está o problema? Só porque o entrevistador faz diferente? Meu Deus.
JensG
9
Também deve ser mencionado que, para certas linguagens e IDEs (Java / [Eclipse | NetBeans | etc], C # / Visual Studio, ...), o IDE está compilando tudo em segundo plano em tempo real, conforme você digita, em efeito, dando-lhe um ciclo de feedback imediato sobre se você cometeu um erro. Seria de esperar que os desenvolvedores de IDE tivessem alguma pesquisa apoiando essa abordagem de compilação conforme o uso.
Ogre Psalm33

Respostas:

223

Existe realmente um benefício em compilar à medida que avança?

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

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

Para emprestar seu exemplo, digamos que você estava codificando em uma linguagem C e se esqueceu de }algo em algum lugar no meio do programa.

Se você compilar logo após terminar de escrever a instrução, pode ter certeza de que acabou de introduzir o erro de compilação e poderá corrigi-lo ali e, em segundos.

Se não o fizer, você teria que gastar bastante tempo lendo o código, procurando a posição exata }e certificando-se, depois de localizar o erro de que a correção é realmente o que foi planejado. Isso aconteceria um tempo depois que você deixasse esse 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ê perdeu uma boa quantidade de tempo em questões sintáticas com as quais o compilador está presente para ajudá-lo - uma quantidade de tempo que poderia ser significativamente menor se você compilasse à medida que avançava.

Oded
fonte
72
De fato, para erros sintáticos como esse, os IDEs modernos compilam e recompilam o tempo todo para tornar seu ciclo de feedback o mais curto possível, e é irracionalmente útil para detectar pequenos erros.
Phoshi
12
@CaptainCodeman - eu diria que existem alguns erros de compilação que exigiriam que você vasculhasse bastante código. Isso é mais verdadeiro para bases de código maiores e conjuntos de alterações maiores.
Oded
29
Às vezes, o compilador fornece um quebra-cabeça em vez de uma dica, como erros de modelo do gcc.
Pjc50
14
@ pjc50: absolutamente (o que é mais fácil de lidar, não alterando muitas coisas de uma só vez antes da próxima compilação, para que você saiba exatamente o que mudou finalmente).
Doc Brown
21
A idéia não é apenas compilar aleatoriamente. É compilar em cada etapa significativa, compilar quando você espera que ainda funcione corretamente. Por exemplo, compilarei para testar para garantir que os objetos sejam criados / excluídos corretamente ou para garantir que os eventos sejam disparados corretamente para uma nova classe que criei. Se eu criar uma classe e conectá-la ao meu programa de alguma forma, quero ter certeza de que a fiz corretamente antes de conectar mais coisas ao meu aplicativo. Menos importante com aplicativos pequenos, vital para os grandes.
Thebluefish
108

Compilar é uma forma de teste, especialmente em idiomas que fazem uso extensivo de tipos como Haskell ou ML . Em outros idiomas, é uma varredura sintática que conta pouco.

Dito isto, "compilar à medida que avança" me parece um hábito muito situacional. Você poderia igualmente ser marcado por ser "nervoso" por compilar com mais frequência do que o preconceito pessoal do entrevistador. Parece nitpicking; ninguém gosta de admitir que um entrevistado foi aprovado no teste; inclina as escalas da negociação salarial.

Nem todos os sistemas de construção são rápidos. Eu trabalhei em um projeto (C ++), onde Marca iria gastar 30 segundos apenas status 'ting tudo para determinar se ele necessária para construir ou não, e a maioria dos arquivos levaria um par de minutos para construir se você fez alterações. Relutamos em fazer isso com mais frequência do que a cada 10 a 15 minutos. Alguém sem dúvida fornecerá uma anedota sobre quando compilar envolve levar seu baralho de cartões perfurados e carregá-los para um prédio diferente ...

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

pjc50
fonte
25
Quando você levar seus cartões perfurados para os sysops para carregar, certifique-se de que nunca os solta, porque colocá-los de volta na ordem certa é um PitA real! Ah, nos dias em que uma ferramenta essencial de depuração era uma faixa elástica.
Gbjbaanb
3
Quando comecei a programar, medi meu progresso pela quantidade de código que eu poderia escrever sem compilar - essencialmente pela qualidade do meu compilador mental. No começo, eram alguns caracteres, depois algumas linhas. Agora eu não ligo para isso. Compilei muito para pequenas mudanças das quais só quero ver os efeitos, compilei muito pouco ao fazer o layout estrutural do projeto.
Phil
Hmm. Só quero dizer que um arquivo C ++ bem escrito não deve demorar mais que alguns segundos para compilar. Se for mais longo, é um cheiro de código ruim. E se é tão grande que a marca tem problemas, eu diria que o aplicativo é muito monolítico. O "My" make nunca teve problemas, nem um pouco ao compilar o Linux.
Phresnel #
2
Eram 1,5 milhões de LOC quando saí. Observe que o Linux não é C ++; os modelos parecem ser lentos no gcc, e se você fez algo inteligente e útil que demora a compilar, não há maneira fácil de criar um perfil do compilador para descobrir o que era.
pjc50
21
@gbjbaanb Eu acho que seria melhor dizer "os dias em que o controle de origem era uma faixa elástica". ;)
JasonMArcher 25/06
35

Então, minha pergunta é a seguinte: há algo que eu perdi?

Sim: sua mente não é um compilador. Enquanto um compilador pode fazer n trocas 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 a base de código, quão imerso você está no código, quão limpo é o código, quão complexo é o problema que você está enfrentando, quão cansado você está, se você é frequentemente 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") forçará você a alternar o contexto com o que você está pensando (por exemplo, "esse valor é definido como 5 aqui e depois em o loop for blablabla e o algoritmo complexo produz o valor correto no retorno ") para um problema de compilação que não tem nenhuma relação com o que você está pensando (diferentes arquivos / módulos / funções / pré-condições / sintaxe / nomes de variáveis, pré-condições etc.) )

Quanto mais código você compilar de uma só vez, mais contexto mudará de ideia. 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. Porém, é um grande problema ao trabalhar em uma base de código existente, com várias interdependências (e muitas vezes não documentadas).

Existe realmente um benefício em compilar à medida que avança?

Você minimiza o contexto que sua mente precisa fazer, permitindo que você se concentre mais no impacto e nos efeitos colaterais das alterações que você faz. Também o deixa 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).

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

Ou isso é algum tipo de mito propagado pela comunidade de software de que você deve compilar seu código com frequência?

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

No meu entendimento, esse é um argumento inválido, porque "obter código para compilar" para um determinado comprimento de código geralmente envolve a correção de um número constante de erros de compilação e leva um tempo bastante constante

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

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

utnapistim
fonte
11
"compile e mude dez" - muitas situações em que esta é a menor unidade significativa para tentar; como adicionar um novo parâmetro a uma função e a todos os seus sites de chamada.
Pjc50 23/06
7
Opções de contexto. Ta brincando né? Se falamos sobre compilação automatizada em segundo plano para indicar erros sintáticos no seu código, você está bem. Mas a troca de contexto mais rápida não será capaz de informar se a lógica do algoritmo está implementada corretamente ou se é adequada. Mas é isso que diferencia uma solução de trabalho de um código organizado, livre de erros, organizado de maneira organizada e rápida, mas totalmente errado.
JensG
5
@ Jen, não, não estou brincando. Ter que pular todo o código para corrigir erros de compilação garante que você não pense mais no problema que está solucionando no momento (tira você da zona). Se, em vez disso, você pode compilar à medida que escreve o código, pode continuar trabalhando na verificação do algoritmo - não na sintaxe. A maneira mais rápida de lidar com as alternâncias de contexto é garantir que você não precisará delas). No entanto, meu post assume um mundo ideal (com compilação rápida em C ++ de grandes bases de código e interdependências minimizadas).
Utnapishtim
11
@JensG, que parece ser uma falácia lógica: não se trata de escolher entre código compilado e código de merda, mas sobre os possíveis benefícios de compilar mais de uma vez.
Jorg
11
Duvido que a alegação de que interromper a concentração dezenas de vezes por um curto período de tempo para corrigir erros sintáticos únicos seja mais rápida do que quebrá-lo uma vez e corrigir uma dúzia de erros sintáticos de uma só vez (depois de você se preocupar com o seu algoritmo real). Certamente não é assim que as alternâncias de contexto funcionam na computação (afinal estamos tentando otimizar a taxa de transferência). E eu tenho trabalhado em um projeto com cerca de 500k LoC de código C ++ que evoluiu ao longo de mais de uma década, então espero que ainda não tenhamos adquirido o cartão de inexperiência?
Voo
26

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

Mas, obviamente, há um outro lado disso. Alguns projetos levam um tempo para serem compilados. Eu trabalhei com estruturas que levam 30 minutos ou mais para serem compiladas depois de edições menores. Deus o ajude se você precisar editar um arquivo de cabeçalho. Geralmente, as recompilações completas são feitas da noite para o dia e, se você confiar no compilador para detectar seus erros, ainda existem erros raros que não serão detectados durante uma compilação parcial. Você simplesmente não recompila a cada 5 minutos nessas 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 metade do seu dia compilando valha a pena. É claro que você cometerá erros de digitação ocasionais, mas vou assumir que você pode digitar e ler. Se você tiver a liberdade de escolha, use um estilo de codificação que faça bom uso do layout para destacar visualmente os erros e você nunca mais eliminará uma chave, colchete ou ponto e vírgula. É preciso um pouco de prática e um pouco mais de disciplina do que a maioria está acostumada, mas é possível. Posso escrever código por algumas horas de cada vez, em um editor de texto simples, e compilá-lo pela primeira vez melhor do que nove em cada dez. 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, está em boa companhia. Aqui está Donald Knuth:

Quanto à sua verdadeira pergunta, a idéia de compilação imediata e "testes de unidade" me atrai apenas raramente, quando estou me sentindo em um ambiente totalmente desconhecido e preciso de feedback sobre o que funciona e o que não funciona. Caso contrário, muito tempo é desperdiçado em atividades que eu simplesmente nunca preciso realizar ou sequer pensar.


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

DeveloperInDevelopment
fonte
Discordo que a compilação é gratuita, as distrações são caras! Mas por outro lado, boa resposta, obrigado :)
CaptainCodeman
Talvez eu devesse ter feito o negrito, em itálico "if" e "iff" ... acho que, dependendo do projeto, compilador e ambiente, pode ser bem perto de uma ação livre. Se você tiver uma segunda janela ou tela para saída do compilador, poderá compilar quase sempre que parar para respirar. Se você fosse realmente incondicional (não sou), nem precisaria desviar o olhar do código - desde que o compilador produzisse erros detalhados suficientes para registrar sua visão periférica. Novamente, isso é se a compilação for razoavelmente rápida, caso contrário, veja acima.
DeveloperInDevelopment
2
I hit ctrl-S about once every 30 seconds. Eu provavelmente salvo duas vezes mais lol. É um péssimo hábito. Às vezes, salvei no meio de uma linha de código e salve novamente no final. Sempre que paro para pensar por um segundo e não digito, eu salvo.
Cruncher
21

Há méritos na compilação à medida que avança. Mas concordo plenamente que permanecer na tarefa é uma estratégia de codificação OK.

O benefício mais significativo para a compilação incremental é a mentalidade que muitos entendem se aguardam o final da compilação e teste : no final, estamos mais preocupados em executar o código do que qualquer outra coisa nesse momento. Dizemos "Ah, só precisamos adicionar esse colchete para que o compilador pare de reclamar" ou "oh, só precisamos capitalizar isso" sem pensar se há um erro semântico subjacente que esse erro de sintaxe oculta. Realmente acho que erros sintáticos geralmente se aninham em erros semânticos (o inverso não é verdadeiro).

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

Lan
fonte
5
+1 para destacar a conexão entre erros semânticos e sintáticos #
Doc Brown
15

Entendo os benefícios de testar seu código à medida que avança, mas por que compilar?

Mas como você testará seu código à medida que não compilar de acordo?

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

Então, nem todo mundo faz TDD, pelo menos nem sempre (eu também, eu admito). Com 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 com mais frequência - o que não é possível quando você não o compila regularmente. E quando seu teste falha, você está executando a depuração (o que pode ajudá-lo a entender por que o algoritmo de boa aparência que você escreveu alguns minutos antes não se comporta tão bem quanto você pensou que deveria). E quanto mais código você escreve sem compilar, maior o código que você escreve sem testar; portanto, é mais provável que você se depare com um caso em que não possa prever que o tempo para corrigir o problema seja "O (1)", como você escreveu.

Doc Brown
fonte
11
Eu concordo com você, mas acho que há uma diferença entre compilar um programa porque você deseja executá-lo versus compilar quando não há nada significativo para testar (ou para corrigir erros de compilação).
CaptainCodeman
@CaptainCodeman: Acho que ao escrever 100 linhas de código, quase sempre deve haver muitas peças pequenas que podem ser testadas individualmente. 100 linhas de código geralmente significam algo entre 4 e 15 funções (ou> 20, se você codificar no estilo de Bob Martin).
Doc Brown
5
@CaptainCodeman: No TDD, nunca há "nada significativo" para testar. O exemplo clássico é que você deseja escrever uma nova classe (vamos chamá-la de Foo); então, a primeira coisa a fazer é criar um teste de unidade e escrever new Foo();que obviamente não será compilado, pois você não escreveu a definição da classe. No TDD, esse é um motivo válido para executar um compilador - isso prova que seu teste de unidade está funcionando (por falha).
slebetman
@lebetman: obrigado por esse comentário útil. Gostaria de acrescentar que o IMHO não se restringe ao TDD. Ao escrever 100 linhas de código, sempre há algo significativo para testar, se você faz TDD ou não.
Doc Brown
14

Na verdade, eu 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 significativamente o suficiente com o tempo para se preocupar. Se fosse possível adiar a correção de todos os erros do compilador até 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 afirmar o óbvio, a compilação é necessária para executar o programa, e a execução do programa é necessária para encontrar todos os bugs de tempo de execução mais complexos, sutis e interessantes criados por desenvolvedores experientes. E esses tipos de bugs são mais difíceis e, portanto, mais caros para corrigir quanto mais você adia a depuração, porque eles podem criar ou mascarar uns aos outros.

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

A fim de não marcar você para baixo, a confiança teria que ser justificada. Se você tivesse passado 45 minutos escrevendo algo sem compilar e precisado de mais 45 minutos para depurá-lo, eu teria pesado muito contra você.

Karl Bielefeldt
fonte
8

A única coisa importante sobre compilar com frequência, ausente de outras respostas, até onde posso ver, é a seguinte: se você compila raramente e recebe uma grande quantidade de erros do compilador, a maioria deles não tem sentido, porque são gerados pelo primeiro erro. Pode ser porque você teve um erro de digitação, erro de digitação ou sintaxe simples que invalida alguma declaração.

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

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

hyde
fonte
Curiosamente, esse é um bom motivo para compilar regularmente, mesmo que a compilação seja lenta . Bom ponto.
sleske
3

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

Depois de conhecer uma linguagem suficientemente bem (ou seja, quando você não precisa mais pensar na sintaxe e apenas codificar a funcionalidade), você tende a não cometer erros sintáticos simples. Aqueles que você faz geralmente são erros de digitação ou erros de copiar e colar e podem ser limpos em pouco tempo com apenas alguns passes de compilação.

Escrevo regularmente código o dia todo sem compilar, depois compilarei e corrigirei os erros de sintaxe e os avisos que o compilador relata antes de confirmar meu código (com uma observação que diz "precisa ser testado!" ). Não tenho problema em limpar mais de 1.000 linhas de código C ou C ++ em apenas alguns minutos.

Depurar e testar, por outro lado, é o que leva um tempo. Os erros de lógica surgem por todos os tipos de razões e eu ainda não encontrei um compilador que me falasse sobre a sub-rotina que esqueci totalmente de escrever ou notará que minha árvore binária não funciona porque eu colei node->leftquando deveria ter sido node->right.

Embora eu ache geralmente imprudente brigar com um entrevistador, eu diria que, se você acha que vale a pena defender seu estilo, deveria ter salientado que se deixou tempo suficiente para depurar o código que escreveu. É isso que nenhum bom programador negligencia.

ps - Se eu estivesse assistindo você revisar o código lendo-o, teria contratado você imediatamente. Isso é o que um profissional faz, sempre.

par
fonte
4
"Ainda tenho que encontrar um compilador que me fale sobre a sub-rotina que esqueci totalmente de escrever". Eu confio totalmente no compilador para me dizer quando não concluí mudanças de longo alcance. Às vezes, até renomeio uma variável para impedir a compilação bem-sucedida até verificar todas as instâncias de seu uso e dar a elas todo o novo nome. Não entendo como você pode dizer que não encontrou um compilador que não o avise se algo estiver faltando. A menos que você esteja escrevendo sub-rotinas vazias e esquecendo-as, nesse caso, o céu o ajudará.
Ian Goldby
@par Obrigado pela sua resposta; É bom saber que eu não sou o único que codifica assim!
CaptainCodeman
3
@CaptainCodeman Estou ciente de que erros de lógica são mais traiçoeiros do que erros de compilador. Mas foi sua afirmação de que um compilador é incapaz de lhe falar sobre a falta de código que eu queria contestar. A menos que você esteja deliberadamente escrevendo código errado (ou incompleto) que compila…, mas que derrota o argumento de que erros que o compilador não pode detectar são o verdadeiro problema da IMO. Caramba, eu até uso o compilador para mover o cursor para a linha em que eu preciso escrever um código. Mas talvez eu seja muito preguiçoso.
Ian Goldby
11
@IanGoldby: Você errou completamente o assunto e eu chegaria ao ponto de dizer que optou por distorcer minhas palavras. O compilador não pode avisá-lo sobre a falta de código da mesma maneira que não posso lhe dizer o que você comerá no café da manhã amanhã. Introduzir erros de sintaxe intencionalmente para que o compilador o lembre de algo é uma técnica de programação; não se qualifica como um erro ou fornece superpoderes psíquicos ao compilador.
par
11
@par Peço desculpas pela ofensa que obviamente causei com o meu comentário - não foi intencional e certamente não pretendi deturpar o que você disse. Vejo agora que, quando você escreve um código incompleto que, apesar de tudo, compila, é uma prática para garantir que ele não possa ser esquecido adicionando #warning ou TODO. Essa é uma técnica legítima. O importante, com o qual ambos concordamos, é que o código que compila, mas não funciona, é muito mais perigoso do que o código que não compila.
Ian Goldby
3

Não, não é razoável adiar a compilação até que você tenha criado uma quantidade suficiente de código (e uma 'quantidade suficiente' depende do codificador e do código que está sendo gravado).

Por exemplo, se você é um codificador incrível que leva o tempo necessário para acertar e não está escrevendo quantidades maciças ou código complicado, compilar regularmente é um desperdício e provavelmente uma distração também. Caso contrário, compilar todas as funções pode ser uma coisa boa. Isso depende da pessoa.

Como um contra-exemplo, imagine que você está escrevendo código JavaScript - não há compilador. Em vez disso (dada a natureza da maioria dos códigos 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é escrever código suficiente para fazer sentido. Como resultado, os desenvolvedores de JavaScript tendem a "compilar" o mais rápido possível, o que não é necessariamente com muita frequência.

Em resumo, não há resposta correta aqui - o entrevistador não está errado, mas você também não. Faça o que o torna produtivo e esqueça o que alguém lhe diz que você deve fazer. Existem fatores muito mais importantes sobre a codificação do que sua tendência a bater F7regularmente (ou não) não tem absolutamente nenhuma conseqüência.

gbjbaanb
fonte
Seu segundo parágrafo não é claro; convém editá-lo, para ficar claro se o "incrível programador" deve compilar regularmente ou não. (Você adicionar um "t" e altere "não" para "não"?)
DougM
@DougM - ta demais.
Gbjbaanb
Muitas vezes, o código de script é desenvolvido "ao vivo", ou seja, é executado no ambiente REPL. Portanto, a "compilação" acontece o tempo todo, a maior parte do código gravado no arquivo de origem também foi executado uma vez. Nem todos escrevem código de script dessa maneira, mas eu diria que qualquer pessoa que se acostume com a relativa "segurança" de linguagens estaticamente tipadas e erros de compilador dados por código incorreto, eles devem trabalhar em linguagens de script dessa maneira.
Hyde
2

Com um bom ambiente de desenvolvimento, vejo poucas razões para compilar, a menos que você esteja planejando testar o código. As ferramentas de verificação de sintaxe de segundo plano capturam quase tudo o que o entrevistador parece estar falando, embora eu admita que ainda existam alguns casos (envolvendo alterações que se propagam por arquivos) que nem sempre são totalmente identificados.

Dito isto, tentarei compilar e executar praticamente a menor unidade de código que pode realmente produzir um resultado. Há meia hora, 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.

Loren Pechtel
fonte
1

Na minha opinião e na minha experiência, se um pedaço de código é compilado ou não é essencialmente aleatório, envolvendo coisas como falta ou não-ponto-e-vírgula e pouco tem a ver com a correção do programa subjacente. (Para mim, focar na compilação é como executar um artigo em uma verificação ortográfica sem revisão para verificar a gramática.)

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

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

Se você me der um pedaço de código incompleto, a primeira coisa que faço será lê-lo. Nem tentarei compilá-lo até saber o que o código está fazendo e o algoritmo está correto.

Se você espera trabalhar no código escrito por outra pessoa, nem sempre você tem tempo para ler tudo. A boa notícia é: código bem escrito tem baixo acoplamento e deve permitir que você raciocine independentemente 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.

"obter código para compilar" para um determinado comprimento de código geralmente envolve a correção de um número constante de erros de compilação e leva um tempo bastante constante, o que deve ser o mesmo se você fizer isso depois de terminar de escrever o código ou se você intercala com o seu tempo de codificação.

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

EDIT: Eu também posso fazer uma analogia com o controle de fonte, quando uma equipe inteira está trabalhando nas mesmas fontes. Compilar à medida que avança é como fazer confirmações frequentes, ajuda a evitar muita dor no final quando você precisa mesclar e resolver tudo.

Você diz que desabilita itens como linhas vermelhas no seu texto. Você também faz isso ao digitar um email ou escrever um documento técnico? Em seguida, você deve revisar todas as páginas novamente, em vez de corrigir erros.

Outra vantagem é que, ao trabalhar no seu código, se você o mantiver compilando ou quase compilando o tempo todo, poderá se beneficiar de muitos recursos IDE semânticos (renomeação, refatoração segura, localização de usos de um símbolo ...) .

Se você quiser entender melhor como esses recursos ajudam, tente habilitá-los e praticar para experimentar seus benefícios. Você também pode tentar programar em pares com qualquer pessoa que esteja acostumada com eles e ver como eles se beneficiam.

Eldritch Conundrum
fonte
11
Normalmente desativo os "recursos" irritantes do compilador, como formatação automática, desenho de linhas vermelhas no texto, etc., pois acho que sou mais produtivo sem esses recursos estúpidos.
CaptainCodeman
1

Pensei um pouco mais sobre isso, porque senti que havia algo muito, muito errado com o entrevistador e não consegui dizer exatamente o que é. Aqui está o problema: para qualquer código que escrevi nos últimos vinte anos, a quantidade de tempo necessária para transformar um algoritmo viável em código compilado foi mínima. Qualquer ganho de eficiência nessa área tem tão pouco impacto no tempo total de desenvolvimento que é totalmente desprezível, e um entrevistador que rejeita um candidato por ineficiências percebidas nessa área não tem idéia do que faz um bom desenvolvedor.

A maior parte do tempo deve ser gasta na coleta de informações sobre o que o código deve fazer, na coleta de informações e especificações sobre serviços externos que precisam ser usados, criando um design global que levará ao código correto e de manutenção, em vez do código cortado e à descoberta de algoritmos. isso levará ao código ativo, em vez do código que será corrigido juntos até que funcione (código que obviamente não possui erros vs. código que não possui erros óbvios).

Depois, dedique uma pequena quantidade de tempo escrevendo o código que é compilado.

Em seguida, vem uma quantidade maior de tempo gasto para garantir que o código funcione e para que saibamos que o código funciona e continuará funcionando. Isso é feito escrevendo testes de unidade, percorrendo o código e, em grande parte, tendo um código bem projetado em primeiro lugar.

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

gnasher729
fonte
Isso faz muito sentido. Na minha opinião, um bom desenvolvedor deve ser capaz de escrever código no papel o dia todo e, no final do dia, digitá-lo.
CaptainCodeman
1

A vantagem de "compilar à medida que avança" é que você recebe feedback constante e não terá chance de dar muito errado 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 é. Em outras palavras, "compilar à medida que 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".

Tom Au
fonte
este não parece oferecer nada substancial sobre o que foi publicada em antes 16 respostas
mosquito
2
Obrigado, mas de que tipo de perda estamos falando? Certamente, a menos que você tenha feito algo drástico como escrever acidentalmente no idioma errado, nunca precisará reescrever nenhum código simplesmente por causa de erros de compilação.
CaptainCodeman
@CaptainCodeman: Faz as empresas se sentirem melhor e é uma forma de "seguro". Isso é algo que custa dinheiro, mas faz com que a maioria das pessoas (incluindo gerentes) "durma melhor à noite".
Tom Au
@gnat: O ponto que eu estava tentando ressaltar era que a maioria dos benefícios eram de nível "corporativo", e é algo que o programador deve fazer porque o chefe o mandou, não porque o programador acha que está certo ou errado.
Tom Au
pontos positivos a favor de um "ciclo de feedback mais curto" já foram feitos e bem explicados na primeira resposta aqui; Eu honestamente não vejo como recheio nua na dúvida sobre "As empresas nos dias de hoje", acrescenta alguma coisa digna sobre o que já foi afirmado
mosquito
1

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

Nas minhas entrevistas, faço exatamente o oposto: os candidatos não podem usar um compilador. Eles escrevem programas curtos no quadro branco e depois discutimos sobre eles. Descobri que muitos desenvolvedores usam o compilador (ou intérprete) como muleta, e isso é uma perda de tempo muito maior do que compilar com pouca frequência. Se estou oferecendo muito dinheiro e você nem consegue escrever o FizzBuzz corretamente sem um compilador, você nunca vai cortá-lo a longo prazo, trabalhando em problemas 100x 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 da empresa. Uma boa pergunta para entrevista deve indicar os objetivos da pergunta e como o entrevistado será avaliado. Iniciar uma pergunta complicada sobre o entrevistado e 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 velhos - não é treinada para entrevistar outros programadores; portanto, confiam nos clichês e fazem os mesmos tipos de perguntas que fizeram quando entrevistaram, sem muita dúvida se essas são técnicas eficazes para avaliar candidatos. ou não.

Não estou afirmando que minha abordagem é a "única maneira verdadeira", 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 beliches. Você precisa fazer o que funciona para você e sua empresa.

Mark E. Haase
fonte
0

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

Para testar essas partes menores, você precisa compilar.

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

Per Alexandersson
fonte
0

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 fornecerá uma imagem maior.

Laurent
fonte
isso parece não oferecer nada substancial sobre o que foi postado em 15 respostas anteriores
gnat