Revisões de código, quais são as vantagens? [fechadas]

Na minha equipe, não fazemos revisões formais de código. Tendemos a pensar que é o suficiente com programação de pares e pares rotativos frequentemente.

Devemos considerar a revisão formal de código? Quais seriam as vantagens?

Fazemos revisões de código um pouco diferentes (talvez).

Criamos todos os programadores juntos (toda sexta-feira) e olhamos o que fizemos em um período de semanas. Em seguida, escolhemos quais projetos queremos revisar para que todo projeto concluído / em andamento tenha pelo menos uma ou poucas pessoas. Então, em uma hora, mais ou menos, olhamos para as mudanças que foram feitas, procuramos erros, como outros projetos funcionam etc. Depois discutimos, contamos os erros, como deve ser feito (não corrigimos bugs, apenas os indicamos e spam o código com FIXME). No geral, geralmente para nós (10 programadores) leva cerca de 2 horas.

Os prós:

• Todo membro sabe o que acontece na empresa
• Os erros são encontrados mais rapidamente
• Nos obriga a escrever código legível (código que pode ser lido sem explicação ou introdução!)
• Métodos de otimização / truques / programas produtivos se espalham mais rapidamente
• Programador como especialista "evolui" mais rapidamente
• É divertido

O que tenho contra a programação em pares, como mencionado (com certeza é apenas minha opinião pessoal), é que quanto mais tempo a equipe trabalha em conjunto - mais rápido fica.

Espero que isso traga um pouco de reflexão. Boa sorte.

Você pode ler este livro gratuito:

http://smartbear.com/best-kept-secrets-of-peer-code-review/

Claro, eles têm um produto para oferecer, mas ainda existem muitas informações úteis.

Eles também discutem como a programação em pares oferece algumas das mesmas vantagens; portanto, se você estiver em programação em pares, talvez não precise da revisão do código.

Não tenho muita experiência em revisar em seu ambiente. Não fazemos muita programação em pares aqui, fazemos revisões de código para espalhar o conhecimento do software na equipe, temos outro par de olhos para identificar os erros e temos um ponto formal para verificar se o software segue as nossas diretrizes de codificação .

Os dois primeiros pontos são razoavelmente bem abordados pela programação do par, o terceiro é muito dependente do par e pode melhorar com uma revisão formal do código.

Você deve fazer revisões formais de código?

absolutamente

Apenas como uma observação rápida, tenho muito pouca experiência com programação emparelhada, mas não acredito que as revisões entrem em conflito com esses métodos.

Eu apresentaria duas formas de revisão de código:

Revisões de código por pares

Mesmo que a programação emparelhada funcione para você, nunca é demais chamar a atenção para o código. Os benefícios para isso são:

1. Ele ganha um novo olhar sobre o código, alguém que pode ter um conhecimento mais íntimo das áreas da base de código com as quais você (e / ou seu parceiro) pode não estar tão familiarizado. Isso pode expor problemas indiretos.
2. Isso faz com que você (o par) volte a validar sua solução antes do envio. Como o revisor não sabe nada sobre o que você escreveu, você deve explicá-lo na íntegra. Isso pode expor casos extremos nos quais você não pensou ou lógica inválida.

Revisões de código por pares (no meu mundo) são realizadas antes de cada envio. Como isso se repete no mundo da programação emparelhado, não tenho certeza.

Revisões de código de grupo

Isso acontece com menos frequência do que as revisões de código por pares. Geralmente, eu puxava meu grupo (ou uma subseção do meu grupo) em uma sala de reuniões para uma revisão informal do código. Geralmente, eu escolhia algum código que foi escrito por uma pessoa aleatória na equipe, de preferência um código que foi escrito do zero - o código refatorado não expõe problemas como código novo.

Certifique-se de que todos saibam que essas revisões não são destinadas a brasas e não são usadas para refletir o desempenho. Eles são apenas para garantir que os padrões de codificação de sua equipe sejam seguidos e ajudar todos a serem melhores engenheiros e, assim, tornarem-se mais úteis para a equipe (e para o crescimento da carreira, etc.) - e garantir que essa seja a verdadeira intenção das revisões. . Se alguém suspeitar de algo diferente, isso se tornará temido e menos produtivo.

Eu examinaria o código de maneira informal, deixando que qualquer pessoa na sala apontasse soluções diferentes que eles possam ter ou falhas lógicas que encontrarem. Isso pretende ser mais uma discussão em grupo do que um líder sentado, dizendo a todos como eles devem codificar.

Descobri que o emprego desses dois métodos aumenta a taxa de progresso dos engenheiros e diminui consideravelmente a contagem de bugs :)

Eu nunca fiz programação em pares na prática (só esperava isso), então não posso comparar diretamente as duas práticas. No entanto, posso contar minhas experiências com revisões formais de código.

Eu costumava liderar revisões formais de código em um projeto anterior, no código legado. O projeto estava completamente confuso e a gerência acolheu qualquer iniciativa com a esperança de trazer ordem ao caos. Naquela época, eu pensei que a revisão formal de código era uma boa idéia. Encontramos bugs e vimos que a qualidade do código recém-escrito era significativamente melhor do que a do código antigo. Eu coletei estatísticas, contagem de bugs etc. para provar isso.

Realizamos uma sessão por semana, em média, envolvendo 3-5 pessoas. Cada sessão levou cerca de 3-4 horas por pessoa (incluindo preparação) e revisou 200-300 linhas de código (LOC) *. Nesse ritmo, durante um período de mais de 6 meses, conseguimos revisar cerca de 5K LOC, de cerca de 50K.

Em retrospecto, acho que foi muito caro. Com esse ritmo, levaria cinco anos para revisar toda a base de código herdada. A OTOH, com mais de uma sessão por semana, teria retirado recursos do desenvolvimento. Obviamente, esse é o dilema típico do código legado. Mas mesmo revisar formalmente todo o código recém-escrito levaria muito tempo, retardando significativamente o desenvolvimento.

Minha conclusão é que as revisões formais de código são melhor executadas em códigos recém-escritos, focados nas partes mais críticas do código. O restante é melhor tratado de maneira mais informal, possivelmente por meio de programação em pares. Esta é apenas a minha opinião atual, que pode mudar. Não pretendo ser um guru de revisão de código nem nada.

* Esse é o ritmo normal das revisões formais de código.

As taxas típicas de revisão de código são de cerca de 150 linhas de código por hora. Inspecionar e revisar mais de algumas centenas de linhas de código por hora para software crítico (como software incorporado crítico de segurança) pode ser muito rápido para encontrar erros.

Citado na Wikipedia (ênfase minha).

A razão subjacente da revisão de código existe porque os programadores isolados precisam conhecer e discutir seu código e verificar se ele está de acordo com seu padrão.

Como você não menciona nenhum problema de qualidade, parece que sua equipe já está fazendo análises de código suficientes por meio da programação em pares. Impressionante!

A programação de pares feita corretamente torna supérfluas as revisões formais de código. Mas experimente por algumas semanas e veja como funciona, mas suspeito que você não notará nenhuma melhoria.

Lembre-se de que as revisões de código são um processo cansativo e caro, e não devem ser levadas em consideração. Introduz essencialmente uma entrega no seu projeto, que é cara e atrasa tudo . É muito melhor garantir que o código esteja correto em primeiro lugar, em vez de tentar encontrar problemas mais tarde.

Talvez. Revisões de código levam tempo. Eles só valem a pena se o tempo gasto pela revisão for economizado em outro ponto do processo. Que economia você espera das revisões de código? Você está enfrentando dificuldades que poderiam ser evitadas pelas revisões de código?

Se você estiver fazendo programação em pares, a necessidade de uma revisão de código diminui substancialmente, mas você certamente se beneficiaria de uma revisão por pares. Para que isso seja benéfico, deve ser feito por alguém mais experiente e experiente do que os membros do par.

Quais são os benefícios? Bem, seria melhor se você considerar os riscos de não fazê-lo.

• O par pode estar fazendo algo errado ou talvez de uma maneira subótima
• Talvez você não esteja seguindo os padrões de codificação ou não esteja documentando o código corretamente. Uma revisão por pares é realmente boa em encontrar esses
• Ninguém além do par entende um pedaço de código específico. Então, o que acontece se os dois membros saírem e o código estiver mal documentado? Outros vão perder tempo tentando entender as coisas. Ter uma terceira pessoa que sabe o que você fez reduz o risco.

Estou divertido que as pessoas tenham dito que a revisão de código é uma perda de tempo. Sim, isso leva tempo. Talvez não produza nenhuma alteração no código, mas isso não significa que seja desperdiçado. É como dizer que você não precisa verificar seu sistema de incêndio regularmente porque é uma perda de tempo.

Para mim, a principal vantagem das revisões de código é que isso faz as pessoas escreverem melhor código.

Saber que seu código será lido e revisado torna você mais consciente da legibilidade e da "correção" do seu código. Quando você sabe que o código está indo direto para o repositório e ninguém mais o lerá, a menos que esteja corrigindo defeitos, você tende a deixar as coisas escaparem, como não refazer o nome dos campos quando o uso deles muda, deixando métodos não utilizados por aí, caso possam ser fatorado de volta em etc. etc.