Como você avalia a qualidade do código de um potencial empregador antes de tomar uma posição? [fechadas]

Na minha experiência antes de começar a trabalhar para uma empresa, você não tem oportunidade de examinar a base de código (perguntei e, por motivos de confidencialidade, todo mundo sempre disse não, acho que é justo). Portanto, durante o processo de entrevista, o que você acha que são as perguntas mais importantes a serem feitas para descobrir em que estado o código está (afinal, se for um cachorro, você vai ficar com os pobres infelizes que precisam passear todos os dias)?

ATUALIZAR:

Uma lista de verificação: pergunte;

• O que eles pensam da base de código. E quando o fizer, preste muita atenção às expressões faciais e ao tempo que elas levam para responder. [Anon]
• Qual é o nível de CMM da empresa [DPD] (e se você ouvir o Nível 5 executar o outro caminho [Doug T])
• Qual ciclo de vida eles usam [DPD] (E se você ouvir "Agile", é quando você começa a fazer algumas perguntas penetrantes para tentar descobrir se por "Agile" eles significam "Codificação ágil ou" cowboy "[Carson63000])
• Quais ferramentas eles usam para avaliar a qualidade do código? [DPD]
• Quais ferramentas eles usam para o desenvolvimento? [DPD] (procure por ferramentas de refatoração e servidores de criação contínua)
• Qual sistema de código-fonte (controle de versão) eles usam e um bom acompanhamento é perguntar por que eles o usam. [Zachary K].
• Como são os procedimentos de teste? [Karl Bielefeldt] (Procure especialmente equipes que usam estruturas de simulação e enfatize testes de unidade automatizados por meio de estruturas estabelecidas como NUnit / JUnit; não se deixe levar por equipes que não usam TDD de desenvolvimento orientado a testes, mas seja desconfie se eles não consideram o teste parte integrante e a pedra angular do desenvolvimento sólido de software. Procure equipes com testadores dedicados.)
• Que tipos de atribuições são dadas aos novos desenvolvedores? Para desenvolvedores experientes? Karl Bielefeldt
• Quantas pessoas trabalham em um projeto? Karl Bielefeldt
• A refatoração é permitida? Incentivado? Karl Bielefeldt
• Quais alterações de processo ou arquitetura relacionadas à qualidade estão sendo consideradas ou foram feitas recentemente? Karl Bielefeldt
• Quanta autonomia os indivíduos têm sobre seus módulos? Karl Bielefeldt
• Você desenvolverá projetos mais recentes (desenvolvimento greenfield) ou projetos legados (desenvolvimento brownfield)? (O desenvolvimento greenfield geralmente é mais divertido e tem menos problemas, pois você não está limpando os erros de outra pessoa).
• A taxa de rotatividade de funcionários é alta na organização ou na equipe? (Isso geralmente indica uma qualidade mais baixa do código) [M.Sameer]
• Alguns problemas de programação de sua preferência; mas evite parecer um idiota. [Sparky]
• Como os desenvolvedores colaboram e como o conhecimento é compartilhado entre a equipe? (Isso deve corresponder à sua personalidade; eu diria que uma mistura de trabalho solo e em pares é provavelmente a melhor, com a proporção que corresponde às suas necessidades sociais)
• Qual a proximidade do banco de dados do 3º formulário normal (3NF) e se ele se desvia de onde e por quê? (Se eles disserem "3NF ???", saia. Se não, e pode haver boas razões para isso, então descubra o que são).

NOTA: Aceitei a resposta de Anon porque, após cerca de uma semana, a comunidade acha que é a melhor - acho que isso sugere que é apenas algo para o qual você precisa desenvolver um sexto sentido. Mas acho que todo mundo tem algo valioso a dizer.

Em vez de pedir para ver seu código, pergunte o que eles acham da base de código. E quando o fizer, preste muita atenção às expressões faciais e ao tempo que elas levam para responder.

Em seguida, aplique seu conhecimento dos gestos não verbais da sua cultura para interpretar o que eles realmente estão dizendo. Para uma empresa norte-americana, o seguinte deve ser preciso:

• Um pequeno encolher de ombros e uma resposta rápida de "poderia ser melhor": provavelmente é muito bom.
• Uma longa pausa, respiração ofegante, talvez uma pequena risada: não é agradável, e as pessoas que você está entrevistando não se sentem confortáveis ​​em dizer isso.
• Olhos revirados, resposta rápida de "é péssimo": pode ser bom, pode ser ruim, mas há jogos políticos acontecendo. A menos que você esteja pronto para jogar esse jogo ou que não seja ninguém quieto, fique longe.
• Sobrancelhas levantadas ou contraídas: elas não entendem a pergunta e a base de código é quase certamente podre.

Obviamente, se você tiver problemas com a comunicação interpessoal, isso pode não funcionar para você.

Estou surpreso que você tenha perguntado. Nenhuma empresa irá mostrar o código antes de você ingressar. Nem mesmo os consultores entraram em contato com o processo, a menos que tenham assinado um acordo de confidencialidade.

Aqui está o que você pode pedir para descobrir.

• Qual é o nível CMM da empresa (idealmente 5)
• Qual é o processo seguido no seu projeto em potencial (BTW, pedir isso é bom porque mostra que você está interessado nesse "trabalho" e não apenas em qualquer trabalho)
• Que ciclo de vida eles usam (não julgue se não ouvir "Agile". Eles podem ter um motivo válido para usar os modelos da velha escola)
• Pergunte se eles usam alguma ferramenta e métrica para verificar a qualidade do código. E se sim, qual (se eles usam pelo menos uma ferramenta para métricas e outra para qualidade, é um bom sinal.)
• Observe também quais ferramentas eles usam. Se é uma ferramenta cara, como o Resharper, em vez de uma ferramenta freeware, eles levam muito a sério a qualidade.

1. Pergunte se eles usam o controle de origem.
   • Sem controle de fonte? -> código provavelmente uma merda
2. Pergunte a eles com que frequência as revisões de código.
   • Nenhuma revisão de código? -> o código pode ser suspeito (mas não necessariamente, especialmente se for uma equipe pequena composta por desenvolvedores decentes).
3. Pergunte a eles como eles testam e implantam antes de entrar em produção.
   • Nenhum ambiente de teste? Implantação direta na produção? -> código provavelmente uma merda.
4. Pergunte a eles se eles fazem integração contínua (ou seja, executando compilações com Hudson)
   • Sem integração contínua? -> código pode ser suspeito, mas não necessariamente.
5. (Relacionado ao item 3), pergunte a eles se o ambiente de teste é separado do ambiente de desenvolvimento?
   • Teste é dev? -> não é um bom sinal, a menos que estejam realmente sem dinheiro, mas quanto custaria uma caixa extra?
6. Pergunte se eles revisam uma lista de ações antes de implantar na produção.
   • Nenhuma revisão de ações antes da implantação da produção? -> Juju ruim.
7. Pergunte a eles quantas etapas são necessárias para que eles façam uma compilação.
   • Mais de 3? -> juju tipicamente ruim.
8. Eles usam (ou estimam) métricas de código como complexidade ciclomática ou LCOM (uma medida da coesão de classe).
   • Sim? -> provavelmente (mas não certamente) um bom sinal em relação à qualidade do código.
   • Não, mas eles entendem os conceitos (pelo menos complexidade ciclomática)? -> difícil de dizer
   • Eles acham que a complexidade ciclomática é um prato exótico ou afrodisíaco de Timbuktu (em outras palavras, eles não sabem o que é isso)? -> possível juju ruim.
   • Eles acham que isso é uma merda irrelevante (ou algum outro tipo de comportamento)? -> fugir.
9. Pergunte a eles como eles controlam os bugs.
   • Eles rastreiam o número de bugs em relação a alguma métrica (por exemplo, por projeto, número de módulos alterados ou número de solicitações de requisito / alteração, algo!)? -> bom sinal sobre seu código (e seu processo de software).
   • Eles fazem o procedimento acima e tentam prever o número de possíveis erros que podem encontrar em um projeto futuro (ou em andamento) com base em uma métrica esperada (número de solicitações de mudança, tamanho do projeto, etc.)? -> sinal muito bom.
   • Eles controlam os bugs apenas para resolução de bugs? -> difícil de dizer
   • Nenhum rastreamento consistente? -> fugir.

Isso seria do alto da minha cabeça. Você notará que algumas das minhas perguntas se referem ao processo de desenvolvimento de software, e não apenas estritamente à codificação. A qualidade do posterior é uma função direta da qualidade do anterior.

Com isso dito, quando você fizer essas perguntas, prossiga com cuidado. Estude-os e selecione alguns no momento da entrevista.

Você deve ter em mente algumas coisas. Uma boa equipe de desenvolvimento ficará feliz em ouvir uma pessoa entrevistada fazer essas perguntas ... desde que sejam feitas com tato. Faça algo errado e você dará ao entrevistador uma impressão de arrogância e perfeccionismo. Não importa o quão boa seja uma equipe de desenvolvimento, nenhum grupo é perfeito e todos eles têm problemas a resolver, comprometimentos na qualidade e tal. Eles querem um jogador de equipe com uma propensão à qualidade, não um perfeccionista disruptivo. Por isso tem cuidado.

Além disso, pode haver casos em que você tenha uma equipe de boas pessoas que, por circunstâncias externas, trabalhe em código de qualidade inferior (eles podem ser desenvolvedores juniores ou simplesmente herdaram uma pilha de porcaria em que agora devem trabalhar com recursos limitados). recursos dedicados à melhoria da qualidade.) Você pode trabalhar com códigos de merda e ainda ter uma boa experiência de trabalho se as pessoas ao seu redor também forem boas pessoas (pessoalmente e profissionalmente). Dê a eles a impressão errada quando fizer as perguntas, e elas podem evitar contratá-lo completamente (roubando a oportunidade de trabalhar com pessoas boas em uma situação muito difícil e desafiadora).

• Aliás, acredito sinceramente que é necessário que um desenvolvedor de software tenha trabalhado pelo menos uma vez com algum tipo de código além da esperança (ou quase além da esperança). Você sobrevive a isso e faz um bom trabalho, essa é uma lição valiosa.

Você também pode encontrar um grupo de desenvolvimento de merda com pessoas de merda. Obviamente, então, o código deles será uma merda e eles serão reprovados em qualquer uma dessas perguntas. Eles podem desprezá-lo por fazer perguntas difíceis (e, portanto, podem fazer um favor a você), ou contratarão você porque precisam de você (mesmo que sejam / sejam incapazes de trabalhar com você).

Quando isso acontece, você deve se perguntar se precisa muito desse trabalho. Às vezes você faz, e você tem que mergulhar em uma pilha de espaguete. Às vezes você não (ou seja, você pode dar ao luxo de não fazê-lo).

Essas são as coisas que você precisa levar em consideração quando / se você optar por perguntar a um entrevistador sobre a qualidade de seus processos de código e software.

Em vez da qualidade real do código, prefiro procurar uma empresa em que a importância da qualidade do código seja bem compreendida.

Por exemplo, digamos que a empresa A tenha gerentes que acreditam que "o planejamento é perda de tempo" e "podemos corrigir problemas de design posteriormente (por exemplo, quando o inferno congelar. Teremos tempo então)". Mesmo que essa empresa tenha uma boa base de código agora, ela não a terá por muito tempo. E você será quem será (forçado a) piorar as coisas.

Por outro lado, digamos que a empresa B tenha uma base de código ruim, mas a gerência entende que a qualidade do código está causando todos esses bugs e atrasos, eles vêem a necessidade de mudança e estão dispostos a fazer algo a respeito (por exemplo, em larga escala refatoração ou mesmo reescrita). Essa empresa melhorará sua base de códigos e você poderá ajudá-los a fazer isso acontecer.

Eu sei onde eu gostaria de trabalhar.

Há uma chance de 99,9% de você não conseguir ver o código antes de começar. (A menos que eles lançem produtos de software livre, é claro)

Então, o que você pode fazer, eu perguntaria sobre processo, em geral, um bom processo produzirá um bom código. Eu começaria com o teste de Joel e perguntaria sobre o método de desenvolvimento. Também vá além do básico. Por exemplo, eu sempre pergunto qual sistema de código fonte eles usam, então um bom acompanhamento é perguntar por que eles o usam.

O local em que trabalhei com código de alta qualidade basicamente não permitiu que dois terços dos desenvolvedores tocassem no código. Os outros escreveram scripts automatizados de teste de caixa preta. Se você se mostrou digno de alterar o código real, os requisitos foram tão extremamente especificados que basicamente não passou de uma transcrição para o código-fonte. Os scripts de teste foram realmente mais divertidos de escrever.

Os lugares em que vi o código de qualidade mais baixa eram exatamente o oposto: apenas programadores relativamente pouco treinados ou não-treinados alguma vez tocaram no código, geralmente porque era uma ferramenta não diretamente relacionada ao produto da empresa ou considerada experimental.

Os lugares mais agradáveis ​​para trabalhar têm um equilíbrio. Novos desenvolvedores recebem atribuições reais, mas são orientados. Existe um bom departamento de controle de qualidade e um processo de revisão por pares para detectar seus erros. Você não é punido por cometer erros, mas deve corrigi-los e aprender com eles. Ocasionalmente, um módulo mal escrito cai nas brechas, mas você não é criticado por gastar tempo melhorando a qualidade do código quando se depara com elas. A empresa como um todo está continuamente se esforçando para encontrar novas maneiras de melhorar o código.

Portanto, as perguntas que eu faria para avaliar a qualidade do código são:

• Como são os seus procedimentos de teste?
• Que tipos de atribuições são dadas aos novos desenvolvedores? Para desenvolvedores experientes?
• Quantas pessoas trabalham em um projeto?
• A refatoração é permitida? Incentivado?
• Quais alterações de processo ou arquitetura relacionadas à qualidade estão sendo consideradas ou foram feitas recentemente?
• Quanta autonomia os indivíduos têm sobre seus módulos?

Como @DPD e @Zachary disseram, processo e SDLC são fatores muito importantes, mas quero acrescentar outros fatores que, de acordo com minha experiência, têm um impacto significativo na qualidade do código:

• Pergunte se você irá trabalhar no desenvolvimento de um projeto relativamente mais novo ou na manutenção de aplicativos herdados. Os aplicativos herdados tendem a ser menos limpos que o projeto mais recente.
• Tente saber se a taxa de rotatividade de funcionários é alta na organização ou na equipe. Isso provavelmente diminuirá a qualidade do código também.

Observe que um processo ajuda muito, mas não oferece imunidade total contra os fatores acima. Quando muitos desenvolvedores transmitem um projeto, todos vêm com uma mentalidade diferente. O arquiteto e o desenvolvedor não seguirão exatamente o que seus antecessores fizeram, o que levará a algumas inconsistências.

Minha atitude é essa, código é código, se é ruim, bem, é um desafio torná-lo melhor. Se é bom, bem, é um desafio ainda mais difícil torná-lo melhor!

O mais importante para mim é se eu quero trabalhar para a empresa e as pessoas com as quais tenho a oportunidade de interagir. O código pode ser alterado, as pessoas não podem ...

Em tom de brincadeira eu digo, entrevista comigo .

Normalmente, uso um bug real (já corrigido) em nossa base de código como um teste de entrevista, para que você veja algum código real. Código geralmente um pouco complicado, e possui um bug.

Encorajo todos a usar essa técnica, pois você já sabe que o bug é real, o problema é real e você sabe quanto tempo levou para encontrar e corrigir.

O melhor é que você pode ter um problema mensurável e difícil.

Eu usei um problema muito difícil como última pergunta da entrevista para separar os especialistas dos muito bons.

A relevância para a pergunta do OP é que todo mundo que faz uma entrevista física vê algum código. (Nada com conteúdo confidencial da empresa)

Se você não podia usar essa técnica, por exemplo, palavrões na base de código, o teste funcionaria, pois os funcionários em potencial perguntariam "posso ver o código" e a resposta seria "oh, você não pode" cheio de palavrões ".

Obviamente, a resposta padrão "tudo é segredo da empresa" é total.
Minha prova: no meu empregador anterior, uma parte não confidencial de um serviço militar produto era o exemplo de código para a pergunta da entrevista. [Felizmente não classificado]

Deixo o problema de determinar a qualidade dos desenhos classificados antes de trabalhar lá para alguém mais inteligente que eu. Sugiro que seja comum que classificado seja sinônimo de livre de supervisão.

É duvidoso que eles deixem você ver o código deles, mas você pode ter uma idéia de como pode ser se você lhes der uma tarefa de programação. Muitos lugares oferecem aos entrevistados uma tarefa de programação que podem ser usados ​​para avaliar você. Retorne o favor - espere um deles para que você possa avaliar melhor o que poderia estar se metendo.

Pergunte o que é necessário para o código entrar na construção da produção. Se você entender 'uhh ... o desenvolvedor o compromete ...', então é quase certamente lixo.

Há várias coisas que tendem a aumentar a qualidade do código (obviamente, não há garantias).

• Análise estática (no .NET são coisas como fxcop / stylecop)
• Um subconjunto (ou conjunto completo) do conjunto de testes - unidade / integração / regressão / manual etc.
• Buddy build (outro desenvolvedor da equipe cria as alterações para ver se há algum problema dependente da máquina / usuário - às vezes executando uma sanidade rápida também)
• Revisão de código

Isso pode ajudar a melhorar, não apenas a força do código, mas a qualidade do código.

Pergunte a eles sobre o teste de unidade. Se eles levarem isso a sério, o entrevistador provavelmente terá algumas opiniões definidas sobre o assunto e ficará feliz em compartilhá-las. Se as respostas são vagas, é um grande sinal de alerta.

Se for uma loja Java, pergunte a eles que biblioteca ORM eles estão usando. Se eles criaram os seus próprios, então poderia ser de qualquer maneira - poderia ser ruim ou poderia ser bom. Se eles não estiverem usando nenhum, corra para a porta imediatamente.

Essa é uma tarefa difícil, porque existem tantas práticas ruins de codificação, que você nunca poderá prever todas elas.

Você não pode, infelizmente. Nenhuma empresa permitirá que você veja seu código (mas eles pedirão para ver SEU código ...), e as chances são de que se você fizer perguntas sobre o ambiente em que você será totalmente enganado ("Controle de versão? Claro ... nós usamos .. uhh .. pensando Sub .. Sub-algo ") ou enganamos sobre a qualidade (" Estamos usando o melhor e mais recente .NET 4 "apenas para descobrir que, enquanto eles usam o .NET 4, eles ' re escrevê-lo como o .NET 1.1).

Fui queimado por isso muitas vezes no passado e ainda tenho que encontrar uma boa maneira de avaliar a qualidade. Geralmente, a melhor maneira é usar seu próprio julgamento e, se tudo se resumir a ele, saia imediatamente se for pior do que você pensava; você pode acabar trabalhando em um emprego, mas manterá sua sanidade.