É possível que um bom programador nunca tenha usado o controle de versão? [fechadas]

73

Estou procurando um programador especialista para ajudar a resolver uma situação difícil.

As entrevistas até agora foram surpreendentemente decepcionantes. O melhor candidato até agora é um programador muito experiente que nunca usou software de controle de versão.

O problema em si pode não ser muito sério, porque é algo que pode ser aprendido em pouco tempo.

Mas há um aspecto mais profundo, que me preocupa:

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

version-control experience

— Lortabac
fonte

25

Quem disse que ele não precisava de controle de versão? Ele precisava disso, e acho que ele fez manualmente. Disse que um programador que faz isso parece ser muito resistente a aprender algo novo - esteja preparado para isso.

— Doc Brown

6

@ e-MEE depende, você pode aprender a atualizar / resolver / confirmar em 30 a 60 minutos, mas ninguém aprende como um (d) vcs funciona em uma hora. A maioria das pessoas que o usam há anos ainda não o entendem.

— atamanroman

3

@ConradFrix Carrot Cake :)

— Chad Harrison

7

É possível para um bom programador nunca ter usado controle de versão, se o calendário diz que hoje é 1981.

— Kaz

7

Isso soa como um caso clássico de alguém que não tem 10 anos de experiência, mas sim 1 ano de experiência repetido 10 vezes.

— Jeanne Pindar

90

Trabalhei por cerca de 11 anos em empresas que não usavam o controle de origem. Conseguimos (principalmente comentando alterações e mantendo o código em um servidor central que poderia ser recuperado para qualquer data). Nós nunca realmente perguntamos se havia uma maneira melhor. Dito isto, também foi nos dias em que eu tinha toda a biblioteca do MSDN em forma de livro na minha mesa.

Sim, havia programação antes da internet.

Eu luto para ver como você pode passar mais de 10 anos no setor agora sem ter passado pelo controle de origem. Mas, eu teria alguma simpatia, acreditaria que era possível e não rejeitaria o candidato apenas por esse detalhe. Gostaria de investigar e descobrir como o candidato conseguiu isso.

Como alternativa, eu poderia questionar se meu processo de entrevista foi o problema. De que maneira ele era o melhor candidato? Existem outras técnicas modernas de programação para as quais ele não tem e que não estou fazendo as perguntas certas? Se eu estivesse fazendo as perguntas certas, outro candidato brilharia?

Como nota final, porém, não tenha medo de rejeitar todos os candidatos, se você tiver preocupações. É demorado começar de novo, mas é mais demorado contratar a pessoa errada.

— pdr
fonte

17

+1, é uma resposta interessante. No entanto, eu não concordo muito com "naqueles dias, o controle da fonte custa um bom dinheiro" . RCS existe há 30 anos, CVS - 21 anos; Ambos são de código aberto.

— vartec 2/10/12

8

+1: Eu ainda trabalho aqui . Finalmente estamos recebendo controle de fonte gerenciada este ano (em grande parte devido a mim). Eu não acho que estamos todos os desenvolvedores terríveis, como resultado de não ter até agora, mas eu estou muuuito maldito feliz que está entrando

— oliver-Clare

3

Se o candidato entender os princípios do controle de origem, não vejo problema. Um desenvolvedor experiente deve ser capaz de captar a "sintaxe" de qualquer sistema que você use rapidamente. Uma pergunta que eu faria - é toda essa experiência em um site? Nesse caso, talvez ele não tivesse autoridade para poder introduzir um sistema. Se a experiência dele tiver sido com empresas diferentes, eu procuraria um pouco mais. O número de empresas, com equipes de desenvolvimento, que não usam controle de origem deve ser mínimo hoje em dia.

— BIDeveloper 02/10/12

4

+1 para o ponto de fazer as perguntas certas. Eu me perguntava o que o tornava o melhor candidato também.

— shambulator

3

@ Ramhound: e você acredita que, ao fazer o controle de origem manualmente, precisa de menos hardware e menos tempo para backups? Para minha experiência, o oposto é bem verdade.

— Doc Brown

49

Eu acho que depende da atitude dele. Se ele é um programador muito experiente e um bom programador, acho que ele seria capaz de escolher um sistema de controle de versão rapidamente. Ele pode falar sobre isso de duas maneiras:

Boa

Eu nunca usei o controle de versão, mas estou muito animado para aprender e parece que isso realmente ajudaria a tornar o desenvolvimento mais eficiente. Não precisei tanto disso porque trabalhei em projetos sozinhos.
Ruim

O controle de versão é apenas uma palavra da moda que está morrendo lentamente na indústria. Estou acima do controle de versão.

— Comprimidos de explosão
fonte

17

Concordo que poderia ter sido válido há 10 anos, mas hoje em dia? Eu diria que não "Good / Bad", mas "Bad / Horrible"

— vartec

24

Mesmo se você estiver trabalhando sozinho, usar um VCS é extremamente valioso. Depois de passar de um projeto de "está quase funcionando" para nunca fazê-lo funcionar novamente, e de não ter como voltar à versão "quase funcionando", prometi colocar tudo em um VCS, por menor que fosse o projeto .

— Alroc

11

"Estou muito empolgado em aprender" - este não é um produto comercial caro, como o Coherence. O controle de origem é algo com que qualquer pessoa pode se familiarizar. Se você ler algum blog sobre desenvolvimento de software, esteja ciente disso.

— andy arrancar

7

+1 para esta resposta. Não é a marca de um bom programador que ele / ela tenha todas as habilidades. É que ele / ela pode adquirir qualquer habilidade necessária.

— Steven

2

@ Steven: Não. De maneira alguma. Por essa lógica, uma criança de 8 anos poderia ser contratada porque poderia pegar a programação. Na IMO, há, ou deveria haver, habilidades básicas necessárias para ser considerado um programador. A proficiência em uma linguagem de programação é uma, o conhecimento e o uso de qualquer VCS são outra. Há mais.

— Steven Evers

34

Deixe-me dar uma perspectiva do desenvolvimento de software no DOS e Windows há mais de 20 anos.

O software de controle de versão no mundo Windows / PC geralmente não era confiável no início dos anos 90. O Visual Sourcesafe (VSS) era o melhor baseado no Windows, mas poderia ser peculiar e muitos programadores odiavam. Algumas equipes simplesmente não aceitariam seu uso depois de lidar com essa situação.

A maioria das outras opções de VCS da época não eram baseadas no Windows e, portanto, raramente eram usadas nas equipes de desenvolvimento do Windows. Algumas dessas eram soluções caras e as soluções de código aberto não eram tão aceitas tão prontamente quanto são hoje.

Em muitos casos, no final dos anos 90, início dos anos 00, se uma equipe do Windows não usava o VSS, não usava nada para controle de origem, além das convenções internas. Alguns deles ainda não usam um VCS, apesar da sofisticação do Team Foundation Server (TFS) e de ótimas opções gratuitas, como git e SVN.

É possível que alguém que trabalhou por anos em uma pequena equipe de desenvolvimento do Windows por anos não tenha usado um VCS. Eu entrevistei e até fiz contrato de trabalho em alguns lugares que não os usavam ou que eram muito aleatórios sobre o uso deles.

Portanto, não acho que a falta de experiência de seu candidato nessa área seja um "não" definitivo, mas você provavelmente deseja se aprofundar na situação de trabalho anterior para descobrir por que isso está faltando na experiência deles. Você também desejará explorar a atitude deles em relação ao controle de versão. Eles acham que é uma boa ideia, mas não foram autorizados a segui-la na posição anterior ou acham que é uma perda de tempo?

— jfrankcarr
fonte

18

O VSS não era "peculiar" - era simplesmente ruim. Repositórios corrompidos e perda de dados eram comuns, mas você não pode descobri-lo por semanas ou meses após o problema, a menos que tenha executado uma verificação de integridade diária (e boa sorte se recuperando dela mesmo assim). O bloqueio e compartilhamento de arquivos foram atrozes. Os programadores odiavam isso porque isso tornava suas vidas um inferno - exatamente o oposto do que um VCS deveria fazer.

— Alroc

@alroc - Acredite ou não, havia alguns menos confiáveis e mais peculiares por aí. Tive a infelicidade de usar um por volta de 1995. Nunca tive um problema sério com a confiabilidade do VSS, mas ouvi histórias de aflição de outros. Conheço algumas organizações que deixaram de usar qualquer VCS após experiências ruins com o VSS.

— precisa saber é o seguinte

UGGH, tentamos o controle de fonte do Powerbuilder no passado. Isso nos fez perder ativamente o código fonte. O PB travava e qualquer pbl com check-out ficava inacessível para todos os outros. Que piada isso foi.

— GrandmasterB

Trabalhei por 1,5 anos em uma loja que usava o Visual Source Safe. Um dos melhores programadores arruinaria o repositório toda vez que ele tentasse verificar seu código por telefone (sim, isso foi há um tempo atrás). Um dos meus sistemas VCS menos favoritos.

— GlenPeterson

Usamos tlib ( burtonsys.com/index.html ) em uma tarefa em um ambiente DOS. Concedido isso foi em 2005, mas parecia que eles estavam usando por um tempo.

— Doug T.

29

Você não pode ter controle de versão sem o software de controle de versão? Pergunte como eles gerenciaram seu código. Talvez já existisse um sistema caseiro.

Desejar fazer as coisas manualmente, reinventar a roda e resistir à mudança não são novidade na programação. Você vai babar sobre um candidato que usa o Visual Source Safe e o "apenas" VSS?

Ao tentar encontrar talentos, você deve saber a diferença entre: não pode, não tem e não quer.

— JeffO
fonte

Antes de descobrir sobre o controle de versão e sua utilidade (descobri-o depois de 2 anos de programação amador e não profissional), não era incomum eu ter cinco pastas com "backups" dos marcos do projeto - um VCS primitivo.

— orlp 2/10/12

"Não pode, não, não vai e não foi permitido"? Ouvi falar de lugares que não concordariam em executar o controle de origem porque eles gostavam da selva que era a unidade de rede.

— Philip

19

Não há desculpa para não usar o controle de versão, mesmo para um projeto pequeno desenvolvido por um único desenvolvedor. A configuração do controle de versão local está além do trivial, beneficia imensamente. Qualquer desenvolvedor que não saiba que não pode ser considerado bom nem experiente.

Quanto às empresas que percebem o controle de versão como "novidade", as quais não desejam introduzir:

O SCCS foi lançado em 1972 ( 40 anos atrás )
O RCS foi lançado em 1982 ( há 30 anos ), e é totalmente de código aberto e gratuito
O CVS foi lançado em 1990 ( 21 anos atrás ), também completamente de código aberto e gratuito

— vartec
fonte

20

Não tenho certeza se o SVN é o melhor exemplo para a configuração "além de trivial". Alguns desses arquivos que você precisa editar, direto no repositório, podem ser complicados. A configuração de um DVCS local está além do trivial. E criação de uma conta BitBucket / GitHub e clonagem repos de que não é muito mais complicado

— PDR

9

@artec: O que é além do trivial é git init. A página vinculada poderia me fazer fugir, pois parece bastante complicado.

— maaartinus

7

@artec: Eu diria que git e hg são mais fáceis de entender por um novato do VCS do que alguém que usa o VCS centralizado há anos, e mais fácil do que o CVCS para o novato. Basta olhar para a seção Layout do Repositório nessa página como se você ainda não o tivesse entendido. Então pense "Eu tenho um repositório aqui, quero cloná-lo aqui".

— Pd2

8

@vartec: Hmm. Não posso concordar. Eu gosto de poder ramificar e clonar mesmo quando estou trabalhando sozinho. Às vezes tenho idéias. E às vezes são ruins :).

— Pd2

4

Trabalhei em empresas nas quais a gerência rejeitou o controle da versión. Não era uma opção. E fizemos projetos interessantes e complexos. Eu não acho que sou o pior desenvolvedor por causa disso. Em casa, também não o uso, até agora, embora admita que o considerei.

— Picarus

14

Um programador que nunca usou o controle de versão provavelmente nunca colaborou com outros programadores. Eu provavelmente nunca consideraria contratar um programador, independentemente de outras credenciais.

— JesperE
fonte

34

Discordo. Não usar o controle de origem exigiria um nível de cooperação muito mais alto com outros programadores do que o normal. Eu poderia até mesmo ir tão longe a ponto de dizer que se você veio de um ambiente onde não há controle de origem, então você realmente sabe a importância da co-operação

— oliver-Clare

12

Essa é uma afirmação gloriosamente arrebatadora e evidentemente falsa.

— Murph

3

Eu simplesmente não gostaria de contratar um programador que não sabe usar ferramentas modernas. Ele / ela pode saber escrever um código incrivelmente bom, mas eu consideraria pelo menos o conhecimento básico do controle de versão um requisito absoluto.

— JesperE

6

Muitas pessoas por aqui parecem estar confusas por não terem sido expostas ao VCS e se recusarem ativamente a usá-lo em seu novo trabalho. E se isso simplesmente nunca lhe ocorreu no local de trabalho anterior ou foi verboten pela gerência? Dito isto, essa seria uma questão crítica se eu estivesse contratando, e o desejo deles de aprender seria um requisito difícil para mim.

— György Andrasek

5

É assustador ver tantas pessoas aqui acharem realmente a falta de controle de origem algo normal ou aceitável.

— JesperE

12

Parece uma bandeira vermelha, mas aprofunde-se mais no porque ele não a usou. Eu ainda esperaria que um desenvolvedor solo usasse o controle de versão, especialmente em dez anos, mas eu perdoaria mais do que se ele estivesse trabalhando em equipe e nunca tentasse trazer o controle de versão.

— Eoin Carroll
fonte

6

+1: eu ficaria horrorizado se estivesse desempregado simplesmente porque meu gerente atual não viu a importância do controle de origem. Pelo menos eu uso o controle de origem para todos os meus projetos pessoais, então eu não seria totalmente parafusado por esta situação ...

— oliver-Clare

2

@LordScree - Pode ser difícil trabalhar em um site de grande volume por conta própria, mas você ainda pode aprender a usar o controle de origem fora do seu trabalho.

— Jeffo

9

Eu não seria religioso sobre a falta de experiência em controle de versão. É apenas uma ferramenta. No final, você pode aprender o básico do svn ou git em um dia ou dois. O resto você vai pegar com o tempo. E não acredito que qualquer candidato meio decente não seria capaz de se encaixar se trabalhasse em um ambiente que usa controle de origem.

Usar o controle de origem é mais um hábito do que uma habilidade. Alguém que nunca o usou pode exagerar o esforço necessário e subestimar os benefícios obtidos. Afinal, ele se saiu bem até agora. Somente depois que ele realmente usar o controle de origem, ele crescerá para apreciá-lo.

A pergunta que você deve fazer é: como ele conseguiu na ausência de controle de origem? Isso pode lhe dizer algo sobre ele e como ele gerencia seu trabalho.

— scrwtp
fonte

4

Definitivamente, preciso descobrir como ele gerenciava atualizações, lançamentos, etc., sem controle de versão

— ChrisF

4

Você deixa muita informação de fora sobre a experiência dele.

Basicamente, eu diria que é muito possível que um programador tenha 10 a 15 anos de experiência sem ter que saber sobre o controle de versão. Codificar por 10 anos não é igual a aprender constantemente novas técnicas de programação por 10 anos.

Sou muito jovem e já vi engenheiros de software antigos e "experientes", cujo código eu nunca gostaria de tocar. Dito isto, ele pode ser muito talentoso, mas eu acho que pelas poucas informações, uma vez que ele não é.

Boa sorte.

— cubsink
fonte

4

Pessoalmente, a coisa mais alarmante para mim é que o candidato nunca encontrou sistemas de controle de versão como um conceito ou decidiu que não vale a pena usá-lo. Acho o primeiro cenário altamente improvável, mas, se for esse o caso, leva-me a supor que o candidato tenha sido significativamente isolado durante a carreira, o que levantaria sérias dúvidas sobre seu valor como parte de uma equipe. Especificamente, eles podem ter conceitos muito bizarros sobre como fazer certas coisas e não conhecer a maneira "certa" de fazer as coisas.

Se for o segundo caso, onde eles decidiram ativamente contra o controle de versão, então eu me assumo que eles nunca trabalharam em algo significativo ou são extremamente arrogantes. Ou, na melhor das hipóteses, eles têm maneiras realmente terríveis de manter código como comentar blocos e atribuir cada linha de código a um autor, data e número de bug.

— brianmearns
fonte

4

Estou vendo algumas respostas bastante julgadoras aqui que não levam em consideração a pessoa que está sendo julgada.

Pessoalmente, acho que o software de controle de versão é uma ferramenta inestimável. Porém, nem todos temos escolha e controle sobre as ferramentas e processos usados em nossos ambientes de trabalho. Trabalho no desenvolvimento do Windows desde 1990. Conforme publicado por outros, naquele momento não havia muito disponível para o VCS no Windows. Não íamos trazer servidores UNIX apenas para obter um VCS. Isso me fez um programador ruim? Mais tarde na minha carreira, trabalhei para uma empresa com um produto comercial no mercado vertical, onde o controle de versão era um processo, não uma ferramenta. Isso me fez um programador ruim? Meus últimos três trabalhos se apoiaram fortemente nas ferramentas VCS. Isso me torna um bom programador?

Seria ótimo se todos pudéssemos usar apenas as melhores e mais recentes ferramentas, linguagens e tecnologias. Mas a profissão de desenvolvimento de software nem sempre funciona dessa maneira. É um pouco idealista dizer "eu deixaria o emprego imediatamente, se não o fizessem ..." ou "eu nunca aceitaria um emprego que não usasse ..." ou "eu os forçaria a usar. .. " Não estamos todos cercados por uma oferta infinita de oportunidades de emprego, onde tudo funciona exatamente como queremos. Como temos contas a pagar e precisamos de um emprego, lidamos com o que está ao nosso redor.

No final, a resposta para sua pergunta é a seguinte: julgue esse programador por suas habilidades, suas filosofias e suas decisões, não as decisões (possivelmente equivocadas) tomadas pelas pessoas encarregadas de seus empregos anteriores.

— cdkMoose
fonte

4

Se você trabalha com idiotas há apenas 15 anos e não faz nenhum código aberto inteligente ao lado, isso provavelmente refletirá em seu conjunto de habilidades e atitudes. As pessoas são moldadas por seus ambientes. Se não fosse esse o caso, por que olharíamos para o histórico de emprego de alguém?

— Kaz

@Kaz Nós olhamos para o histórico de emprego deles não para a contribuição de colegas de trabalho, mas para a própria. Não podemos julgar alguém na área em que cresceram, caso contrário poderíamos começar a entrevistar vizinhos também.

— James Khoury

Moldados por nossos ambientes, sim, mas não somos definidos por nossos ambientes. Estou apenas sugerindo que o OP tenha uma visão completa do programador e não faça um julgamento severo com base em um critério.

— precisa saber é o seguinte

4

Eu nunca me considerei um "programador" até começar a ganhar dinheiro fazendo isso profissionalmente.

Ganhei bastante dinheiro criando sistemas que tornaram os clientes ainda mais lucrativos. Se eu sou ou não um desenvolvedor "bom", é subjetivo.

Posso fazer o GSD (Get Something Done) rapidamente, o que para o desenvolvimento da web geralmente agrada meus clientes. Eles podem não ver algum código feio nos bastidores, falta de comentários etc.

Eu não tinha usado o Git e não tinha um perfil no Github até este ano, o que eu acho que está muito atrasado em termos de padrões modernos de programadores. Eu também comecei a fazer projetos Rails e Django depois de ter feito PHP, Flash e iOS no passado. Desde então, consegui contratos para desenvolver sites, tanto para clientes quanto para mim, não tem sido muito doloroso aprender algo novo aos 30 anos de idade e alguns anos fora da programação.

Muito na sociedade moderna se concentra em acompanhar os Jones e em se preocupar com o que as outras pessoas pensam. Se você pode romper esses grilhões e considerar o que precisa para o desenvolvimento de seu software (velocidade / tempo de colocação no mercado, gerenciamento otimizado de recursos, código bem documentado, escalabilidade etc.), isso pode ser muito mais do que saber se alguém conhece Mercurial, SVN , Git ou qualquer outro sistema de controle de versão.

Prefiro perguntar aos candidatos a desenvolvedor pelo que eles são apaixonados, qual é o sistema mais legal que eles já criaram em sua própria opinião e em que gastam seu tempo livre desenvolvendo suas habilidades. Se as pessoas não desenvolvem suas habilidades em seu próprio tempo, isso me assusta mais do que outras coisas, mas não significa que tem que te assustar.

Eu acho que você já tem ótimas respostas para essa pergunta das pessoas aqui e isso deve ajudá-lo a tomar sua própria decisão informada com base em seus requisitos.

— ljs.dev
fonte

2

Acho incrível que um profissional de software nunca tenha usado o controle de fonte e eu ficaria muito nervoso em contratá-lo.

Que experiência ele tem. Gostaria de saber o que mais ele não sabe que você ainda não descobriu.

Qual é a sua experiência em desenvolvimento de software? Você está em condições de perguntar a ele sobre arquitetura, padrões de design, problemas comuns de desenvolvimento de software, questões de desempenho do sistema, questões de segurança do sistema etc.?

Se ele se destacasse nesse tipo de coisa, talvez eu pudesse ignorar a falta de conhecimento sobre controle de origem.

— ozz
fonte

2

É possível que um bom programador nunca tenha usado o controle de versão?

Sim. Muitas pequenas empresas com programadores autodidatas não o utilizam.

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

Eu introduzi pessoalmente o controle de versão para duas pequenas empresas, atualizei uma empresa de médio porte de algo horrível para SVN (melhor opção na época) e trabalhei em outra empresa pequena que tinha apenas um VC, escreveu sua própria solução de VC para algum código e tinha muito código simplesmente não em nenhum VC.

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

Bem, não é um fracasso instantâneo, mas eu certamente faria muitas perguntas de acompanhamento. Coisas como:

Você já experimentou algum software de VC? O que? O que você pensou disso? Existe algum motivo para você não usá-lo? O que você usou antes para gerenciar código? Você já trabalhou com alguém na mesma base de código e quais métodos você usou para evitar conflitos?

— James
fonte

11

Nada de novo nesta resposta.

— PDR

11

Hoje, programadores inteligentes e autodidatas conhecem o controle de versão e o utilizam. O resto está com a cabeça presa em algum lugar.

— Kaz

@Kaz Discorda. Acho que é isso que gostamos de pensar, mas conheci programadores que consideraria inteligentes e que não o fizeram, como diz minha experiência pessoal. Não usar o controle de versão é um grande sinal de alerta de que eles podem ter a cabeça presa em algum lugar [frase charmosa :-)], mas nem sempre é o caso.

— James

2

Eu gostaria de concordar com os comprimidos de explosão (mas meu representante é muito baixo, atm ...) ... a atitude é muito mais importante.

Há algumas coisas a serem procuradas, que acredito serem excelentes para a programação:

Comunicação
Criatividade
Compaixão (diga o que?)

E, muitas vezes, mais do que um pouco de TOC.

Você conhece o tipo ... aqueles que ficam sentados lá, martelando em um problema, perdendo-se completamente em seu código enquanto exploram opções. São eles que fazem anotações à medida que avançam, deixam comentários em seu código para garantir que eles entendam seus próprios caminhos lógicos (e para iluminar o caminho para eles ou outros programadores que possam ter que lidar com o código no futuro. .. assim, "compaixão" na minha lista acima!), e transmitir de forma rápida e clara idéias complexas aos tomadores de decisão da cadeia, para que os problemas possam ser tratados com eficiência.

Um excelente programador pode ter ficado parado por anos em um ambiente que não aceitou a idéia do VCS, teve más experiências com o VCS (à la VSS), o que os deixou com muita vergonha de experimentar novos sistemas, mas eu garantiria que um excelente programador nessa situação ainda teria configurado algum tipo de rotina para se proteger de perder todo o seu trabalho para algumas iterações ruins de design.

O tipo de programador com o qual se deve tomar cuidado, portanto, é aquele que afirma nunca ter precisado do VCS, nem qualquer medida de proteção contra inevitáveis falhas. A atitude deles é de "bem, eu a construí, portanto não pode estar errado". Esses são os que eu mais temo do que qualquer noviciado logo depois da faculdade, porque um novato pode aprender a apreciar os pontos fortes do VCS porque percebe o quão pouco realmente sabe.

— Jason M. Batchelor
fonte

2

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

Se ele vem de equipes da velha escola, onde pequenos projetos são gerenciados por uma única pessoa, é muito possível. Ele pode ter 10 anos de experiência no mesmo conjunto de tecnologias sem aprender e se aperfeiçoar.

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

Se o seu candidato estiver em um ambiente de desenvolvimento de equipe (pelo menos 4 ou mais programadores), é uma questão trivial. No entanto, pode haver uma divisão de trabalho entre programadores, trabalhada em módulos atribuídos exclusivamente a eles, o que pode reduzir a necessidade de controlar o código de origem.

No entanto, não ser ouvido sobre o controle de fontes na era da Internet é uma situação realmente surpreendente. Assim, eu examinaria sua disposição em aprender coisas novas (relativas ao seu ambiente de desenvolvimento) e como ele está aberto a um ambiente de trabalho dinâmico.

— ElYusubov
fonte

Nem todo mundo lê blogs de programação / etc. Em particular, alguém que tem uma carreira inteiramente com uma única plataforma herdada não encontrará muito valor imediato com eles. Quantos blogs de software de mainframe / COBOL / RPG (não de jogos) você conhece? A programação dessas plataformas não mudou muito nos últimos 30 anos, e muitas das melhores fontes de informação para elas ainda estão quase certamente no formato de árvore morta. Se a programação é o seu trabalho, versus o que a sua vida gira, quando trabalhar nessas áreas lendo blogs de tecnologia / etc não terá muito ROI de curto prazo.

— Dan Neely

11

Mesmo em um projeto individual, você se beneficia do controle de versão. Se um erro for encontrado, você poderá declarar "que foi introduzido na versão 3.13" e, portanto, os usuários do 3.13 e posteriores serão afetados. Você também pode fazer um patch facilmente para várias versões, para pessoas que não desejam migrar para a versão mais recente. Se você pode fazer essas coisas sem controle de versão, está realizando um controle de versão ad hoc de fato. Você espera que seus usuários usem seu software para eliminar trabalhos manuais trabalhosos e propensos a erros, mas você, o programador, não faz isso sozinho! RI MUITO.

— Kaz

2

A experiência é importante e você está certo de que a mecânica do uso das ferramentas de controle de origem pode ser aprendida rapidamente. Mas você está certo ao ver uma bandeira vermelha.

O seu candidato está isolado da profissão e de suas tendências?
Os muitos outros aspectos do trabalho em equipe também precisam ser aprendidos?

Para mim, a questão sobre o controle de versão é mais um sintoma do que a doença. A causa pode variar e ser bastante benigna. Muitos programadores ad-hoc começaram a fazer o que achavam que fazia sentido, começando com alguns livros sobre programação e não fizeram um estudo sistemático do desenvolvimento de software. Às vezes, mais ainda nos velhos tempos, os graduados em ciência da computação se formavam sem nunca usar um sistema de controle de fonte, porque todos os seus projetos eram projetos individuais e eles foram para empresas com processos de software altamente imaturos.

No entanto, ele chegou lá, se ele é um lobo solitário há uma década ou mais, pode tornar difícil viver com pessoas.

Pode valer a pena perguntar se o seu candidato tem mais algumas perguntas investigativas.

Conte-me sobre uma vez que você trabalhou como parte de uma equipe?
Conte-me sobre um momento em que uma equipe em que você trabalhou teve um conflito entre os membros da equipe?
Conte-me sobre uma época em que você recebeu código de outro desenvolvedor e levou o projeto adiante?
Diga-me como você e outros membros da sua equipe se mantiveram afastados quando criaram código juntos?
Conte-me sobre um problema relatado por um cliente relacionado a um recurso que costumava funcionar, mas não funcionou em uma versão posterior? Como você resolveu isso?
Do que você gosta em trabalhar em equipe?

Ele também pode estar acostumado a ter controle quase completo sobre seus métodos, processos e desempenhar um papel em que é o único especialista em software. Você vai querer alguém que esteja aberto a uma nova maneira de fazer as coisas. Mais perguntas:

Conte-me sobre um período em que você usou ou ajudou a criar um padrão de codificação?
Que tipos de coisas você deseja ver em um padrão de codificação?
Como você se sente ao reescrever o código de outra pessoa?
Conte-me sobre uma vez em que você esteve envolvido em análises por pares de software ou documentação?
Você pode me falar sobre uma proposta ou contrato para o desenvolvimento de software que você estava envolvido por escrito?
Conte-me sobre seu gerente ou supervisor favorito de software?
Conte-me sobre seu colega de trabalho favorito ou subordinado?

— DesenvolvedorDon
fonte

2

No ano de 2012, para alguém com 15 anos de experiência no setor nunca ter usado o controle de versão é uma bandeira vermelha. Pode não ser uma bandeira vermelha se o ano foi de 1982 ou mesmo de 1992. Mas hoje, é melhor haver uma excelente explicação para essa lacuna intrigante no contexto desse desenvolvedor.

Situações extraordinárias exigem explicações extraordinárias.

É como um mecânico de automóveis que afirma que conserta carros há 15 anos, mas nunca conseguiu nem um pouco de graxa em si mesmo.

É claro que se sujar com graxa não conserta a transmissão e nenhuma das etapas do manual de reparo exige isso, mas esse não é o ponto. A questão é que estar completamente limpo é inconsistente com a aparência de mecânicos de automóveis quando eles estão trabalhando. Nesse trabalho, você engorda.

Se você está entrevistando alguém experiente que admite que não tem experiência com controle de versão, provavelmente está exagerando ou fabricando parte de sua experiência (e nem sabe que esse controle de versão é algo amplamente usado e importante, e algo sobre o qual ele também deveria mentir! )

É possível ver todos os tipos de piadistas nas entrevistas. Vi pessoas que não conseguem desenhar um diagrama de uma lista vinculada ou escrever uma função que insere um nó no início de uma lista vinculada. No entanto, eles reivindicaram 20 anos de experiência profissional.

Mesmo os recém-formados em ciência da computação podem ter uma familiaridade passiva com o controle de versão, mesmo que ainda não o tenham feito uso extensivo.

— Kaz
fonte

O melhor que você sempre pode esperar dos recém-formados é: "Ah, eu já ouvi falar disso". Tivemos uma introdução de uma semana ao que era, baseada no Subversion, mas nunca usamos controle de versão para nada.

— Izkata

Sim, e por serem recém-formados, "compramos" isso e seguimos em frente.

— Kaz

"passar a familiaridade" (o que eu acho que você quis dizer na resposta) implica que eles a usaram em algum momento; Estou apontando que você nem pode esperar isso.

— Izkata

Eu diria que, se os graduados em CS não usaram o controle de versão, o departamento de sua alma mater falhou em implementar um curso obrigatório e obrigatório de engenharia de software, no qual os graduandos não apenas aprendem sobre os conceitos de engenharia de software, mas também trabalham em um projeto de equipe (com versão controle e tudo). Eu gostaria de ter uma palavra ou duas com o chefe desse departamento.

— Kaz

Venho programando profissionalmente há quase 20 anos. Eu sei o que é uma lista vinculada e por que elas seriam usadas. Eu nunca usei um e provavelmente enfrentaria dificuldades em escrever sua função. Eu acho que só porque você usa técnicas de 30 anos, dizer que todo mundo deveria é um pouco injusto.

— Página

1

Eu acharia estranho, mas não impossível, para um programa experiente nunca ter usado controle de fonte dedicado. Em uma empresa com a qual trabalhei, eles usaram extensivamente o controle de origem para o código C # e VB tradicional. Mas o código puro do banco de dados (procedimentos e scripts armazenados, bem como as definições de tabela) não estavam no controle de origem, apesar de haver dois Desenvolvedores SQL profissionais cuja tarefa principal era escrever, manter e executar o código puro do banco de dados. Defendi o controle de origem para as entidades de banco de dados de lá e foi apenas parcialmente bem-sucedido.

Em outra empresa, a equipe de desenvolvimento era pequena (um homem comprava por muito tempo e depois dois). O controle de origem do desenvolvedor anterior era ter várias cópias dos arquivos de origem com uma data adicionada no final. Além de não ter um sistema de controle de fonte melhor, meu antecessor era definitivamente competente e um homem inteligente.

Antes de me tornar profissional, eu era um hobby e não usava nenhum controle de fonte, sabia vagamente o que era, mas não me incomodei.

Em resumo, acho estranho que um profissional não esteja familiarizado com isso, mas principalmente se ele estiver acostumado a equipes muito pequenas, certamente é possível ser competente sem ele. Na contratação, eu não seguraria isso contra ele. Eu absolutamente manteria uma relutância em aprender e começar a usá-lo no trabalho contra ele ...

— TimothyAWiseman
fonte

peça ao DBA para gerar scripts SQL a partir do banco de dados e ele poderá colocar os scripts no controle de origem.

— linquize 23/02

@linquize Oh concordou. Essa é uma das melhores maneiras de fazê-lo (embora não seja a única). Mencionei simplesmente que conheci muitos profissionais competentes e um amador habilidoso que não possuía experiência com controle de fonte, especialmente no lado do DBA. Na contratação, eu relutava em aprender o controle da fonte contra uma possível nova contratação, mas não ficaria surpreso demais por não ter usado antes, principalmente se eles estivessem acostumados a uma equipe pequena e estivessem principalmente no banco de dados.

— TimothyAWiseman

1

Meu 2c é que depende de como ele reagiu ao ser perguntado sobre VC. As possíveis reações podem ser:

Hã? O que é isso
Não, nós fizemos
Sem embaralhamento embaraçado , a gerência não nos permitiria
Sem embaralhamento embaraçado , mas eu próprio investiguei um pouco e pensei que parecia algo que deveríamos estar fazendo.

No caso de 4, o cara receberia um passe de mim, ele tem a atitude certa e provavelmente vai se dar bem. No caso de 3, ele recebe crédito por entender que é algo que deve ser feito, mas não tanto quanto 4. Se ele conseguiu citar alguns factóides sobre VC (liste alguns dos pacotes de VC por aí) eu ' tomaria isso como evidência de alguma curiosidade e poderia passar por ele.

Se ele respondeu 1 ou 2, ou seja, se ele soubesse e não quisesse saber sobre VC, eu questionaria seriamente o julgamento do candidato. Haverá outras ferramentas (rastreamento de bugs, métricas de qualidade, automação de construção etc. etc.) com as quais ele precisará trabalhar e você provavelmente descobrirá que tem uma batalha árdua por todos esses problemas, se ele não estiver aberto a tentar novas abordagens.

Como a maioria das pessoas aqui, acho que seria injusto prejudicar o candidato apenas porque o empregador não estava em dia; para mim, tudo depende de como eles reagiram.

— PhilDin
fonte

1

Escrever o que mudou é bom quando se olha para trás. Isso me salvou muitas vezes ao descobrir o que havia de errado e muitos problemas foram resolvidos rapidamente porque eu o escrevi. Na minha opinião, é bom manter um registro. Especialmente se você estiver programando com mais pessoas que você.

Se você estiver escrevendo um aplicativo da Web, poderá continuar adicionando belezas sem controle de versão, porque constantemente adiciona coisas novas a ele. Mas talvez você escreva um registro ou um post de notícias com as novidades.

É tudo sobre o que você está programando.

— Jason Stackhouse
fonte

0

Trabalhei em locais onde o processo de aprovação do software era de 12 a 18 meses. Se ainda não estava na lista de softwares aprovados, não havia como obtê-lo nas máquinas. As unidades de CD / DVD estavam bloqueadas e as máquinas não estavam conectadas à Internet.

O primeiro lugar em que eu entrei no controle de origem da solução foi ter um desenvolvedor escrevendo por conta própria, quando estava pronto para testar o projeto de vários anos que estava acabando. Eles apostaram que escrever do zero era mais rápido que o processo de aprovação.

O segundo lugar em que encontrei esse problema usou o controle de origem nos primeiros meses, mas o cliente queria que todo o desenvolvimento fosse feito em sua rede interna. Eles novamente trancaram tudo, então voltamos a muitas pastas compactadas.

Conheço desenvolvedores que só trabalharam nessas condições. Eles querem usar essas ferramentas, gostariam de usá-las, mas não têm permissão para usá-las.

Investigue por que eles não os usaram. Não entender os procedimentos por causa de zero de experiência é muito diferente de rejeitar as ferramentas.

— mhoran_psprep
fonte

Nada de novo nesta resposta.

— PDR

0

Estou desenvolvendo nos últimos 15 anos. Usou o controle de versão apenas algumas vezes. Ainda estou usando meus próprios scripts e programas agendados para fazer backup de todas as pastas de desenvolvimento incrementalmente. Não sei o que dizer Se alguém me perguntar se eu uso o Controle de versão. Eu nunca precisei do sistema de controle de versão, sempre trabalhei em pequenos projetos. Quero dizer, não sou o melhor programador por aí, mas tenho certeza de que não sou o pior. Na maioria das vezes, tenho vergonha de dizer às pessoas que não uso regularmente o sistema de controle de versão, mas é assim que é para mim.

— Então
fonte

Eu tive uma experiência oposta: algumas pessoas me dão uma aparência engraçada quando digo que uso controle de versão em pequenos projetos em que sou o único desenvolvedor. Talvez menos hoje em dia, porque o controle de versão é usado para hospedar projetos de código aberto e, portanto, é entendido como um método de implantação.

— Kaz

2

Você deve mudar sua atitude e examinar o controle de versão, pois permite fazer muitas coisas facilmente. Por exemplo, o gitsistema de controle de versão possui um fluxo de trabalho automatizado ( git bisect) para encontrar um erro de regressão. Isso realiza a pesquisa binária no histórico da versão de um projeto para tentar encontrar o conjunto de alterações que introduziu o bug. Tudo o que você faz é reconstruir, executar seu teste e informar gitse foi bom ou ruim; em seguida, seleciona e recupera a linha de base a ser testada em seguida.

— Kaz

Em gitvocê pode fazer algumas alterações experimentais e depois colocá-las em um stash. Seu trabalho é revertido para o original e as alterações são salvas. Mais tarde, você pode explorar seu estoque e reaplicar essas alterações para continuar fazendo experiências ou jogá-las fora. E, é claro, qualquer sistema de controle de versão decente possui ramificações, com as quais você pode fazer coisas como desenvolver um recurso, isoladamente, de uma versão estável. Ou volte e corrija um bug em uma versão (para dar um patch aos clientes) e mescle facilmente essa alteração também à versão de desenvolvimento atual.

— Kaz

0

Falando da minha experiência como programador em sistemas IBM MVS: nos primeiros dez anos de minha carreira profissional, o sistema operacional com o qual trabalhei tinha exatamente um tipo de arquivo com versão disponível para o programador: o conjunto de dados de geração. Este era essencialmente um arquivo com um número fixo de versões, e você tinha que lembrar qual versão era o que - praticamente inútil para o controle de versão moderno. Juntamente com um sistema de arquivos que não tinha diretórios reais, apenas mais ou menos qualificadores (8 caracteres), o conceito de sistema de gerenciamento de código-fonte era completamente estranho a qualquer pessoa que trabalhasse naquele ambiente.

Na verdade, não vi um sistema de controle de código-fonte até me mudar para o SunOS 3 e usar o RCS. Naquele momento, eu era um programador de sistemas IBM extremamente fácil, altamente produtivo e muito bom no meu trabalho. Todas as versões eram tratadas copiando backups para fita e gravando o que estava onde.

Se eu ainda estivesse trabalhando em mainframes nesse momento, é perfeitamente possível que eu ainda não tenha sido exposto a um sistema formal de controle de versão; as alternativas especificamente suportadas são o ClearCase e o Rational, nenhuma das quais é gratuita (e na verdade são ambas muito caras).

Dizer que alguém é por definição incompetente porque nunca usou controle de versão é um argumento ilusório. É necessário cavar e olhar para os detalhes. Se eles afirmam ser um desenvolvedor de Linux / Unix / Mac OS, mas nunca usaram o controle de versão, ele fala menos bem para eles, e talvez você precise avaliar se a experiência geral deles é tão boa que você gostaria de treiná-los em engenharia de software moderna. Se eles são um programador de mainframe da velha escola - e é isso que você precisa -, concentre-se em saber se eles têm exatamente as habilidades de programação necessárias que você deseja e resigne-se ao fato de que você precisará ensinar isso a eles. Como outros já disseram, sua resposta ao conceito será o fator decisivo nesse caso.

— Joe McMahon
fonte

0

Muito por favor! Toda a nossa comunidade não vive em comunidades sociais altamente desenvolvidas, onde os hangouts e eventos hacky são excessivamente abundantes, nem todos trabalhamos em empresas de desenvolvimento de software e alguns de nós nem conseguem encontrar recursos publicados relevantes ou atualizados em nossas línguas nativas, impressas ou on-line, vamos encontrar um programador de verdade.

Pelo que entendi, se ele é um desenvolvedor de software experiente, como você diz, provavelmente é um lobo solitário trabalhando como freelancer para pequenas empresas.

— Filip Dupanović
fonte

-1

Existem alguns motivos possíveis para não usar o controle de versão:

Trabalhando em empresas que não desenvolvem software como sua principal linha de negócios.
Ou se o desenvolvedor decidiu usar outro sistema - válido apenas para os experientes.
Ou se o desenvolvedor ainda não aprendeu como cada sistema funciona
Ou é um problema de atitude contra as ferramentas que eles não conhecem

Mas você deve ter cuidado ao encontrar pessoas que assumem:

Que existe apenas uma maneira de fazer algo
Ou que todo programador deve fazer da mesma maneira que está fazendo
Ou que as práticas que as pessoas estão usando são fáceis de mudar

— tp1
fonte

-2

Tão possível quanto um programador ruim seja especialista em controle de versão. O que quero dizer é que não sei o que o controle de versão faz por suas habilidades de programação ou de resolução de problemas. É uma questão de experiência. Muitas lojas menores não a usam ou a deixam para os indivíduos (que frequentemente trabalham sozinhos) para descobrir por si mesmas.

— aserwin
fonte

-2

Eu acho que não se trata tanto de "Como é possível desenvolver ativamente software por 10 a 15 anos sem precisar de controle de versão?", Mas "Como é possível desenvolver ativamente software por 10 a 15 anos sem nunca precisando de controle de versão? "

Certamente é possível programar sem controle de versão, mas um profissional deve estar familiarizado com o estado da arte atual e ser capaz de selecionar as ferramentas certas para realizar o trabalho. Deixar de usar o software de gerenciamento de versão apropriado torna seu trabalho arriscado e não confiável, e um dos motivos pelos quais você deseja contratar um desenvolvedor profissional é que ele deve gerenciar riscos.

Uma base de código que é anotada corretamente em um VCS vale muito mais do que uma que não é. O motivo de cada mudança pode ser rastreado e compreendido, possibilitando aos mantenedores uma compreensão mais profunda do que eles precisam saber. Deixar de fazer isso não é profissional, e a única desculpa seria se ele / ela tivesse sido restringido por gerentes ruins em seu trabalho anterior. Mesmo assim, eles não deveriam ter usado versões para seus projetos particulares?

— Dominic Cronin
fonte