Qual é a maneira mais eficaz de realizar revisões de código? [fechadas]

71

Eu nunca encontrei a maneira ideal de realizar revisões de código e, ainda assim, meus clientes geralmente precisam deles. Cada cliente parece fazê-los de uma maneira diferente e nunca me senti satisfeito em nenhum deles.

Qual foi a maneira mais eficaz de você realizar revisões de código?

Por exemplo:

  • Uma pessoa é considerada a guardiã da qualidade e revisa o código, ou a equipe possui o padrão?
  • Você revisa o código como um exercício em equipe usando um projetor?
  • Isso é feito pessoalmente, via e-mail ou usando uma ferramenta?
  • Você evita revisões e usa coisas como programação em pares e propriedade coletiva de código para garantir a qualidade do código?
por Paddyslacker 07.09.2010 / 19:21
fonte

13 respostas

30

No meu trabalho, temos uma regra muito simples: as alterações devem ser revisadas por pelo menos um outro desenvolvedor antes de uma mesclagem ou um commit no tronco . No nosso caso, isso significa que a outra pessoa senta-se fisicamente com você em seu computador e passa pela lista de alterações. Este não é um sistema perfeito, mas melhorou notavelmente a qualidade do código.

Se você sabe que seu código será revisado, obriga você a pesquisá-lo primeiro. Muitos problemas se tornam aparentes então. Sob o nosso sistema, você tem que explicar o que você fez ao revisor, o que novamente faz com que você perceba problemas que você pode ter perdido antes. Além disso, se algo no seu código não for imediatamente claro para o revisor, isso é uma boa indicação de que é necessário um nome melhor, um comentário ou uma refatoração. E, claro, o revisor pode encontrar problemas também. Além disso, além de observar a alteração, o revisor também pode perceber problemas no código próximo.

Existem duas principais desvantagens para este sistema. Quando a mudança é trivial, faz pouco sentido que seja revisada. No entanto, temos absolutamente que nos ater às regras, para evitar o declive escorregadio de declarar que as mudanças são "triviais" quando não são. Por outro lado, essa não é uma maneira muito boa de revisar mudanças significativas no sistema ou adição de novos componentes grandes.

Já tentamos revisões mais formais antes, quando um desenvolvedor enviava um e-mail para o código para ser revisado para o restante da equipe, e então toda a equipe se reunia e discutia o assunto. Isso levou muito tempo a todos e, como resultado, essas revisões eram poucas e distantes, e apenas uma pequena porcentagem da base de código foi revisada. A "outra pessoa analisa mudanças antes de cometer" funcionou muito melhor para nós.

    
por 26.10.2010 / 23:46
fonte
13

Eu gosto de revisões de código, embora possam ser dolorosas. A razão pela qual eu gosto deles é que eles ficam mais atentos ao código e a uma perspectiva diferente. Acredito que, mesmo com a programação em pares, o código deve ser revisado. É fácil o suficiente para duas pessoas trabalhando no mesmo código coletivamente cometer o mesmo erro que um conjunto diferente de olhos não pode perder.

Se feito como um grupo com um projetor, ele deve ser revisado individualmente antes da reunião. Caso contrário, é apenas uma perda de tempo chata.

Eu só fiz revisões de código por e-mail e em grupo. De um modo geral, não acho que devam ser feitos pessoalmente. Você sente um pouco mais de pressão para percorrer o código com alguém olhando por cima do ombro. Eu acredito que uma ferramenta projetada para revisão de código seria um bom recurso, já que pode ajudar com alguns aspectos mundanos e deve facilitar a identificação de bits problemáticos de código, então é via e-mail.

O problema em ter uma pessoa fazendo todas as revisões de código é que ela pode ser um gargalo. Com padrões de codificação bem documentados e projetados, não deve ser necessário. Dependendo do ambiente / release-schedule, pode ser uma boa ideia ter sempre alguém como revisor de código em espera.

Acredito que a propriedade do código é uma boa ideia, já que essa pessoa pode priorizar o código e potencialmente desempenhar um papel de gatekeeper.

    
por 07.09.2010 / 19:51
fonte
6

No SmartBear , não apenas fazemos uma ferramenta de revisão de código , também usamos no dia a dia. É uma parte essencial do nosso processo de desenvolvimento. Analisamos todas as alterações que são verificadas.

Acho uma má ideia ter um único revisor de código do gatekeeper por vários motivos. Essa pessoa se torna um gargalo e eles têm que fazer muita revisão de código (apenas para manter o projeto em movimento) para realmente ser eficaz (60 a 90 minutos de cada vez é o limite de eficácia). Revisões de código são uma ótima maneira de compartilhar idéias e conhecimento. Não importa quanto de um superstar seja seu gatekeeper, eles podem aprender com os outros membros da equipe. Além disso, fazer com que todos façam revisões de código também cria um ambiente de "propriedade coletiva de código" - onde as pessoas sentem que possuem a qualidade do código (não é apenas o controle de qualidade ou o gatekeeper).

Temos um whitepaper gratuito sobre " Práticas recomendadas para revisão de código de peer "que contém 11 dicas para tornar as revisões de código eficazes. Muito disso é o mesmo conteúdo do livro que João mencionou de uma forma mais destilada.

    
por 27.10.2010 / 18:08
fonte
3

Sem desculpa. Pratique a programação em pares. É a melhor revisão de código possível. Qualquer outro mecanismo resulta em jogo de culpa. A programação em pares induz o espírito de equipe e a propriedade coletiva. Além disso, você debate idéias com seu par, falha rapidamente, toma ações corretivas e é apenas o código codificado e revisado que é comprometido com o Configuration Management System (CMS). Par feliz programação!

    
por 06.07.2011 / 16:55
fonte
2

Se você estiver trabalhando em um projeto no qual várias pessoas contribuirão para a base de código, um padrão precisará ser estabelecido.

Neste ponto, na minha experiência, é melhor designar uma pessoa como o "rei" da revisão de código, se você quiser e o que ela disser. A este respeito, se um usuário não está aderindo aos padrões, o rei cuidará dele.

Como eu mesmo, reviso meu próprio código muitas vezes para ser legível, sensível e tudo o mais. Geralmente usamos javadoc ou similar em determinadas linguagens com as quais codificamos e usamos a tag @author para anexar propriedade a funções, classes etc.

Se uma função não estiver correta, falamos com o proprietário, com a classe etc.

    
por 07.09.2010 / 19:46
fonte
2

Na minha empresa, cada tarefa recebe um testador para testar a tarefa e também um revisor de código para revisar o código.

Se o seu produto já tiver sido lançado e você quiser ter certeza de que não está fazendo nada errado (como vazamento de alça ou vazamento de memória), as revisões de código são ótimas. Acho que durante o desenvolvimento inicial antes de lançar seu produto, as revisões de código podem ser muito trabalhosas.

Se sua equipe tiver todos os desenvolvedores seniores, a revisão por pares ainda será útil. Todo mundo comete erros às vezes. Se a sua equipe tiver alguns alunos da terceira idade e alguns juniores, deixe que os desenvolvedores seniores façam as revisões de código, mas ainda tenham revisões de código para o código do senior.

Uma coisa importante sobre revisão de código é que ele pode detectar erros que cometemos, mas não é um substituto para testes.

    
por 07.09.2010 / 20:18
fonte
2

Eu recomendo usar revisões de código se você não estiver fazendo programação em pares.

Não discutir os prós e contras com o emparelhamento, mas é difícil contestar os efeitos positivos de ter seu código constantemente revisado por (pelo menos) outra pessoa. O código é até escrito e desenhado por (pelo menos) dois programadores - dificilmente pode ser melhor que isso. Eu estou dizendo "pelo menos" porque imo, você deve tentar trocar pares muito para que todos tenham uma chance de trabalhar com o código.

    
por 26.10.2010 / 23:59
fonte
2

Uma das coisas que tento fazer nas revisões de código das quais participo é depois de revisar o código eu mesmo, faço análise estática do código, usando ferramentas como Findbugs, PMD, JavaNCCP et al, e vejo qualquer problema ferramentas encontram dentro do código a ser revisado. Eu particularmente quero olhar para qualquer coisa que tenha níveis incomumente altos de complexidade, pedindo que eles expliquem por que esse nível de complexidade é necessário, ou por que a vulnerabilidade sugerida não é importante.

YMMV

    
por 15.02.2011 / 16:34
fonte
2

Onde eu trabalho atualmente, produzimos dispositivos de hardware e o software que faz interface com eles que entram na infraestrutura crítica. Consequentemente, temos um foco muito alto na qualidade de lançamento. Nós usamos uma variante da Inspeção Fagan e temos um processo de revisão formal. Somos certificados pela ISO 9001, entre outras certificações.

O setor de infraestrutura crítica está muito interessado em confiabilidade e repetibilidade dos mesmos. : -)

    
por 15.02.2011 / 18:54
fonte
2

Na minha empresa, temos revisões de código obrigatórias para programadores juniores e revisões voluntárias para idosos. Não há nenhum revisor de código designado, as solicitações de revisão são enviadas para todos os desenvolvedores.

Este sistema funciona bem - as revisões são feitas quando o tempo permite e as alterações podem ser revistas por vários conjuntos de olhos.

A excelente e gratuita ferramenta Review Board funciona muito bem para nós e provou ser uma excelente forma de comunicar opiniões.

    
por 15.02.2011 / 23:53
fonte
1

Na minha empresa, nunca fazemos revisões formais de código antes dos check-ins, a menos que modifiquemos uma produção altamente crítica e não tenhamos tempo para executar nosso processo de QA padrão.

O que fazemos é que cada vez que nos sentimos como uma revisão de código seria útil, adicionamos um comentário "// todo: code review by joe" ao código modificado. Normalmente, selecionamos Joe porque ele é dono do código modificado, mas se este critério de seleção não se aplica (geralmente, isso acontece), nós escolhemos alguém aleatoriamente. E, claro, se Joe estiver disponível naquele momento, usaremos o bom e velho método de revisão sobre o ombro.

Como revisor, a única coisa que você precisa fazer é pesquisar periodicamente todo o código para "// todo: revisão de código por mim" , revisar as alterações e verificar o código novamente sem o "todo ..." comentário

Se houver um problema, voltamos aos métodos de comunicação tradicionais (mail / chat / etc).

Esse método nos fornece as duas principais qualidades que estamos buscando em um sistema de revisão:

  • sobrecarga muito leve
  • rastreabilidade
por 15.02.2011 / 11:57
fonte
1

Descobrimos que a maneira mais eficaz de fazer revisões de código é a de 1 para 1 usando o github para mostrar as diferenças no ramo.

  • Uma pessoa é considerada a guardiã da qualidade e revisa o código, ou a equipe possui o padrão?

    • Depende do tamanho da equipe - equipe de 3 terá 1 sênior que tenha o melhor conhecimento de boas práticas, enquanto uma equipe de 12 pessoas poderá ter 3 ou 4 pessoas que desempenharão esse papel.
  • Você revisa o código como um exercício em equipe usando um projetor?

    • Pessoalmente. 1 em 1 para ser menos ameaçador. Às vezes feito na área comum embora para disseminação de conhecimento. Depende da situação exata, pessoas, horários, etc.
  • Isso é feito pessoalmente, via e-mail ou usando uma ferramenta?

    • Pessoalmente. Usamos o git e o github e ele possui ótimas ferramentas de revisão de código e comparação de diferenças para facilitar a revisão de código.
  • Você evita revisões e usa coisas como programação em pares e propriedade coletiva de código para garantir a qualidade do código?

    • Tentamos fazer as duas coisas conforme apropriado. Isso significa que, quando se deparar com um problema particularmente espinhoso, ou quando estiver trabalhando em uma infraestrutura básica ou ao se preparar para férias ou deixar a empresa, o emparelhamento pode ser feito para compartilhar e transferir conhecimento. A maioria dos códigos ou códigos que têm algo mais do que mudanças estéticas devem ser revisadas no final.

Como em todos os itens de codificação, a resposta certa deve levar em consideração:

  • Tipo de empresa (por exemplo, startup vs. grande corporação)
  • Tamanho da empresa
  • Número de desenvolvedores
  • Orçamento
  • Prazo
  • Carga de trabalho
  • Complexidade do código
  • Capacidade do (s) revisor (es)
  • Disponibilidade do (s) revisor (es)
por 21.02.2013 / 03:33
fonte
0

Eu trabalhei em muitas empresas e vi muitos processos. Minha equipe atual lida com isso da melhor maneira que já vi até agora.

Usamos um processo de desenvolvimento ágil e, como parte disso, temos portais pelos quais cada história tem que passar. Uma dessas portas é a revisão do código. A história não se move para testar até que a revisão do código seja feita.

Além disso, armazenamos nosso código no github.com. Então, depois que um desenvolvedor finaliza a alteração, ele publica o link no (s) commit (s) da história.

Em seguida, marcamos um colaborador para revisar. O Github tem um sistema de comentários que permite que alguém comente diretamente na linha de código em questão. O Github então envia um e-mail para a distro, então às vezes nós realmente recebemos olhos extras de algumas das nossas outras equipes.

Este processo funcionou muito bem para nós. Nós usamos uma ferramenta de processo ágil que facilita a postagem dos commits, além de facilitar a comunicação.

Se um problema é particularmente complicado, vamos nos sentar e discuti-lo. Isso funciona porque é parte integrante do nosso processo e todos compram como o processo funciona. Podemos mover as passagens de volta para o progresso se a revisão do código resultar no retrabalho necessário e, em seguida, ele pode ser revisado novamente após alterações, ou o revisor pode observar na história que a correção dos itens é suficiente e não precisa ser revisada novamente.

Se os testes retrocederem alguma coisa, tudo será retomado e outras alterações também serão revisadas.

    
por 21.02.2013 / 06:22
fonte