Qual é o seu processo de revisão e aprovação de código, e quais são suas vantagens / desvantagens? [fechadas]

5

Sua equipe depende de revisões de código para aprovação do trabalho? É simplesmente o controle de qualidade que assina seus recursos e correções? Você tem um programador líder (ou arquiteto) que analisa o design e a implementação do código?

Ou é simplesmente um Works on My Machine paradigma?

O que você recomendaria ou viu que funciona bem?

    
por gnat 06.01.2011 / 23:48
fonte

5 respostas

4

As revisões de código podem ser imensamente úteis para identificar possíveis bugs e garantir que os desenvolvedores cumpram os padrões de codificação da empresa. No entanto, é importante ter diretrizes claras sobre o que é e não é revisado. Um padrão de codificação escrito - acessível por meio de um navegador da Web - é uma necessidade, na minha opinião. E todos na equipe devem ter a chance de fornecer informações sobre o que acontece no padrão. Quando um revisor sinaliza um defeito, ele deve citar a seção do padrão que o código viola e fornecer um hiperlink para ele.

Ter um padrão escrito e exigir que os revisores o citam para cada item que eles marcam como um defeito tem alguns efeitos importantes:

  1. Isso impede que os comentários fiquem muito pessoais. Os revisores estão apenas verificando a conformidade com um padrão acordado, não "atacando" o desenvolvedor cujo código está sendo analisado.
  2. Os desenvolvedores podem analisar o código com muito mais rapidez quando têm uma "lista de verificação" de coisas que devem ser observadas.

Uma vez trabalhei para uma empresa que decidiu implementar um fluxo de trabalho que usava o Gerrit para revisões de código e exigia uma revisão antes que o código pudesse ser confirmado na ramificação dev - uma decisão strongmente a favor de na época. E eu ainda sou. Infelizmente, não tínhamos um padrão de codificação escrito. Um punhado de membros seniores da equipe achava que isso seria um "exagero", ou "muito restritivo", e achava que existia um padrão "de fato" dentro da cultura da empresa que "todo mundo já conhece". Previsivelmente, as revisões se transformaram em um debate interminável sobre colocação de espaços em branco e chaves, e discussões acaloradas ocorreram regularmente em tópicos que não tinham nada a ver, na verdade, com a qualidade do código ou a execução da missão da empresa.

Então, esse é o melhor conselho que posso dar: ter um padrão de codificação acessível, acessível pela Web (como um ), e exige que os revisores cumpram escrupulosamente ao sinalizar defeitos. Muitos desenvolvedores de software tendem a ter tendências de transtorno obsessivo-compulsivo (suspeito que é isso que nos torna bons em codificação), e se você não restringir isso em revisões de código, eles podem se tornar um púlpito para aqueles que não conseguem isto:

if (!initialized_) {
    initObject(obj);
}

para que eles continuem tentando convencer as pessoas a fazer isso:

if ( ! initialized_ )
{
    initObject( obj );
}

Distinções como essa quase totalmente desprovidas de significado e nunca são um fator determinante no sucesso ou fracasso de um projeto / empresa. Então, deixe a colocação da chave explicitamente não especificada no padrão ou simplesmente escolha algo e exija que todos vivam com ela. Melhor ainda, use algo como uncrustify em um hook de commit para impor uma sintaxe 'padrão'. Uma empresa diferente para a qual eu trabalhei fez isso, e eu achei estranho na época, mas eu totalmente obtenho agora. Qualquer coisa é melhor do que fazer com que os desenvolvedores gastem dinheiro incessantemente debatendo trivialidades. Nós podemos fazer isso durante o almoço. (E nós vamos, de qualquer maneira. É como um esporte para nós.)

Se você tem um padrão publicado que "atinge os pontos altos", acho que a própria equipe de desenvolvimento pode lidar com revisões de código. É assim que fazemos no meu trabalho atual. (Usamos o Crucible , o FWIW, e gostamos muito dele.) O controle de qualidade não está envolvido no processo de revisão em todos. Um desenvolvedor que deseja mesclar seu código simplesmente cria uma revisão e convida outros desenvolvedores a participar. Ele tem um sinal verde para mesclar quando todos terminarem a revisão e todos os defeitos tiverem sido resolvidos. Não há aplicação rigorosa. Você deve "criar" uma revisão de código antes de mesclar sua ramificação de tópico - e quase todo mundo faz isso - mas as circunstâncias ocasionalmente exigem uma fusão "desonesta". Para a nossa equipe de mais de 25 engenheiros, isso funcionou muito bem.

    
por 10.09.2014 / 17:27
fonte
1

A revisão do código de qualidade antes de entrar em produção é definitivamente uma boa prática e é recomendada. A revisão geral de código por outros desenvolvedores de equipe é normalmente feita antes do controle de qualidade. No entanto, o tamanho da equipe, o produto específico, a cultura, etc. determinam como a revisão do código deve ser feita. O que eu recomendo é fazer uma revisão de código com várias pessoas revisando o código. Além disso, se você tiver vários membros da equipe, sugiro que várias pessoas revisem o código e não apenas o desenvolvedor líder. Os membros da equipe com menos experiência podem não conseguir identificar tantos problemas, mas aprenderão não apenas novas maneiras de fazer as coisas e se familiarizarão mais com o código que a equipe suporta.

    
por 07.01.2011 / 00:03
fonte
1

No nosso caso, o código é enviado quando atende aos requisitos especificados. Um processo completo de teste, revisão e validação do software é realizado para garantir que os requisitos sejam totalmente satisfeitos.

Embora tenhamos diretrizes de estilo informais (e revisão de código crítico), essa é uma consideração secundária. Eu trabalho com muita gente inteligente e a qualidade do código raramente é um problema.

    
por 07.01.2011 / 00:05
fonte
1

Code review is very effective when contineous and implicit within the team.

É por isso que não está explícito em nossa definição de concluído .

Veja como funciona:

  • As tarefas não são atribuídas , os membros da equipe podem decidir para trabalhar sozinhos em qualquer tarefa ou parceiro com outro desenvolvedor.
  • Eles comunicam todo o processo e analisam um ao outro.
  • Às vezes, eles decidem fazer par programação , que é, IMHO, o melhor processo de revisão de código de todos os tempos.
  • A programação em pares garante que o código produzido não seja possuído por um indivíduo e atenda às diretrizes de codificação da equipe.

Com este sistema, é muito improvável que um desenvolvedor trabalhe sozinho em seu módulo sem ajuda externa. Esse comportamento é natural quando as tarefas não são atribuídas.

É por isso que é muito importante ter sua equipe localizada no mesmo local, no mesmo escritório ou dividida em duas salas de três mesas.

    
por 07.01.2011 / 10:36
fonte
0

Educação contínua (pelos arquitetos para os desenvolvedores ) das coisas e um espírito de equipe onde todos são responsáveis pelo trabalho estrangeiro também. O controle no sentido de garantia de qualidade é bom, mas não é suficiente na situação crítica do projeto (linhas mortas). Você precisa de coisas que trabalhem duro para alcançar o impossível, tudo junto.

    
por 06.01.2011 / 23:54
fonte