Como é uma revisão de código? [duplicado]

38

Estou escrevendo um documento de processo de revisão de código para nossa equipe; nunca tivemos um processo formal em andamento, embora façamos alguma revisão de código.

Eu encontrei muitos artigos falando sobre o quão importante é a revisão de código, mas tenho uma pergunta em particular que não encontrei a resposta na web ... o programador faz parte da revisão de código? Em outras palavras, uma revisão de código deve ser de duas pessoas sentadas juntas, repassando o que está no código, ou deve ser uma pessoa olhando para o código de outra pessoa?

Na maioria das vezes, nossos projetos são feitos por uma equipe de 2 pessoas, portanto, antes de serem enviados para o controle de qualidade, essas duas pessoas devem se sentar e analisar todo o projeto, incluindo o que cada um deles escreveu? Ou, deveriam apenas olhar o código do outro? Eu posso ver vantagens para cada um.

Por fim, o que acontece com os problemas encontrados durante a revisão de código? Eles são anotados e enviados de volta ao programador? Ou o revisor deve anotá-las e depois corrigi-las? Ou é sempre bom fazer uma mudança e nem mesmo dizer ao programador especificamente o que você achou?

    
por GendoIkari 03.01.2012 / 22:37
fonte

10 respostas

40

Uma revisão formal de código pode ser assim:

  1. O programador envia material ao revisor
  2. O revisor repassa o material
  3. Programador e revisor sentam-se passam pelo material. Programador toma notas. A discussão de design é adiada.
  4. O programador corrige o que saiu da revisão.

O programador deve sempre conversar com os revisores, caso contrário, muita informação será perdida.

Note que, como você é apenas duas pessoas na equipe, provavelmente pode conviver com algo muito informal, como a explicação passo a passo do código na tela do programador.

Observe também que a programação em pares é uma ótima alternativa para revisar.

    
por 03.01.2012 / 22:47
fonte
8

O que você parece estar falando é o que as pessoas chamam de "Programação em Pareamento", sentadas juntas e discutindo seu código para garantir que ele esteja livre de defeitos. Essa é sempre uma ótima ideia e é normalmente incentivada. No entanto, isso não exclui a necessidade de uma revisão formal. Comentários formais fazem com que todos em sua equipe estejam familiarizados com o código, além de mais olhos é sempre uma vantagem!

Uma revisão formal deve sempre incluir sempre o autor, de modo que fique livre para fazer comentários esclarecedores, conforme necessário. No entanto, eles nunca devem ser o líder na revisão. Isso impede que eles tenham muito controle sobre o processo e, possivelmente, ignorem aspectos importantes de seu código.

Muitas das outras respostas cobrem como rastrear os defeitos encontrados durante uma revisão de código, por isso não os reenumerarei aqui, mas é sempre importante fazer anotações durante essas reuniões e reportá-las de volta ao autor. O autor quase sempre deve ser responsável por implementar as mudanças encontradas durante a inspeção.

Na minha escola, meus professores criaram um vídeo de como uma inspeção de código deve ser e quais devem ser os principais papéis. Todos nós achamos muito brega, mas cobre alguns pontos positivos. Você pode assistir aqui: link

    
por 03.01.2012 / 23:07
fonte
4

Na minha experiência, fazer uma revisão de código em uma reunião física formal geralmente resulta em muito pouco código sendo revisado, ou as revisões sendo insatisfatórias. Prefiro muito mais uma ferramenta como o colaborador de código , gerrit ou os recursos internos de revisão de alguns hosts de controle de versão, como o github ou o forno. Isso permite que você informe quantas pessoas precisar ou precisar, e então elas poderão revisar em seu próprio horário (reservo a última hora do dia). O autor original então faz, testa e carrega quaisquer correções e quem encontrou o defeito assina a correção. Isso permite que você tenha uma abordagem mais ágil e iterativa para fazer avaliações, em vez de ser um grande evento no "fim".

    
por 03.01.2012 / 23:02
fonte
3

Na empresa em que trabalho, o processo é bastante simples: a pessoa responsável pede o apoio de um colega (informalmente). O colaborador deve ser alguém que conheça a funcionalidade de confiança (mas isso não é obrigatório).

Fazemos revisões de soluções conceituais e de implementação.

Na revisão "implementação", o responsável explica o problema (se ainda não souber) e a solução (se ainda não souber) e depois passa pelo código e pela documentação interna. Isso acontece na máquina do desenvolvedor (antes que qualquer código seja confirmado). Durante essa fase, o revisor pode fazer sugestões para melhorar o código ou a documentação. Também é comum que o responsável peça feedback sobre questões específicas de implementação (ou seja, mostre duas implementações da mesma função e discuta qual delas é "melhor").

Idealmente, o responsável deve mostrar alguns testes sendo executados com o novo código (e o revisor também pode sugerir outros casos de teste).

Este é um processo simples, mas geralmente encontra pequenos problemas.

Às vezes, há duas solicitações / revisores de revisão (mas isso se deve à organização da empresa: o código é dividido por equipes especializadas e, às vezes, é necessário alterar o código de outra pessoa).

    
por 03.01.2012 / 23:02
fonte
3

Eu concordo com praticamente tudo @ Karl Bielefeldt disse, mas vou adicionar um ponto que eu acho importante:

Revisão de código é (ou deveria ser) programação de pares assíncronos.

A parte assíncrona é obviamente verdadeira somente se o codificador e o revisor não estiverem na mesma sala ao mesmo tempo. Para mim, isso é melhor habilitado por uma ferramenta como o pull request do github. Certamente existem outras maneiras de automatizar o processo, e eu vi uma variedade delas trabalhando em vários domínios, de dispositivos médicos a código aberto; no entanto, o que os separa é a grande variação na eficiência. Eu não conheço ninguém que não esteja preocupado com o comprometimento de tempo envolvido nestes dias; portanto, acho que é melhor automatizar o processo desde o início.

O pedido pull do Github recebe meu voto porque é detectável e facilmente acessível por iniciantes através da interface web, e ainda, lida com usuários mais avançados que preferem a linha de comando.

A outra coisa que eu gosto neste sistema é que ele faz um bom trabalho de separar metadados de revisão (comentários sobre código) do próprio código e foca o revisor na provisão de correções que aumentam a taxa de aceitação.

Se você pensar sobre isso, a economia da revisão de código é algo como: a qualidade derivada da revisão é uma função da iteração: atitude e aptidão do revisor, mais a abertura e a capacidade de resposta do codificador. Qualquer coisa que você possa fazer para aumentar a facilidade e a taxa em que essas iterações de revisão ocorrem produz melhor qualidade e uma experiência mais coesa para a equipe.

Eu também veria Como as revisões de código devem ser realizadas?

    
por 04.01.2012 / 05:00
fonte
2

O processo de revisão com o qual estou familiarizado é o seguinte:

  • O código-fonte é gerenciado usando um sistema de controle de versão (por exemplo, SVN).
  • Qualquer alteração no software é acompanhada por um sistema de solicitação de alteração (por exemplo, Bugzilla).
  • Quando um desenvolvedor verifica algumas alterações, elas são anexadas à solicitação de alteração.
  • Antes que a solicitação de alteração possa ser encerrada, a alteração deve ser revisada por outro desenvolvedor. Isso pode acontecer diretamente (um desenvolvedor explica as alterações ao revisor) ou por meio de uma ferramenta (por exemplo, link ) depois que elas forem verificadas -em já. Nos dois casos, o revisor pode aprovar as alterações ou sugerir modificações adicionais.

Em ambos os casos (revisão direta ou por meio de uma ferramenta), se o revisor aprovar as alterações, a solicitação de alteração poderá ser definida como 'CORRIGIDO'. Se o revisor exigir mais alterações, o desenvolvedor as implementará e uma nova revisão será necessária. É o desenvolvedor original que implementa essas alterações adicionais.

Para alterações maiores (por exemplo, implementação de novos recursos), o desenvolvedor não explica a alteração até os mínimos detalhes: as ideias principais e as técnicas de implementação são ilustradas no código. Para alterações menores (por exemplo, correções de erros), há tempo para uma discussão mais detalhada.

    
por 03.01.2012 / 22:48
fonte
2

A maneira mais simples de fazer uma revisão de código é obter uma ferramenta (usei codestriker ). Então o processo é:

  • o programador escolhe o código para a revisão e os revisores
  • os revisores comentam o código
  • o programador passa pelos comentários e aceita o que é apropriado

Dessa forma, os revisores podem fazer isso quando encontram tempo para isso. E o programador não precisa fazer anotações.

Uma alternativa à revisão de código é a programação em pares. Algumas pessoas chamam de revisão de código em esteróides , mas é muito mais do que isso.

    
por 04.01.2012 / 07:53
fonte
1

O processo básico deve envolver o desenvolvedor sentado com seus colegas e analisando seu código com alguma profundidade. Quão profundo depende do tamanho do projeto, quão importante é, etc. Os revisores devem ter acesso ao código antes da reunião para que possam se concentrar em discutir os defeitos em vez de ler o código.

Cada reunião não deve ser muito longa - cerca de uma hora, portanto, se houver muito código, divida-a em partes mais gerenciáveis. Também é perfeitamente aceitável rever apenas uma parte do código, embora isso dependa da importância do código, etc.

Você pode passar pelo código on-line ou off-line, mas nenhuma alteração deve ser feita durante a reunião. Apenas observe os defeitos como anotações na impressão ou em um arquivo separado.

O desenvolvedor então volta e corrige os defeitos, re-executando quaisquer testes, etc., conforme necessário. Dependendo do número e da gravidade dos defeitos, pode haver outra revisão - embora isso possa ser apenas uma amostra do código.

    
por 03.01.2012 / 22:48
fonte
1

Você está basicamente fazendo duas perguntas:

  1. O autor do trabalho que está sendo inspecionado deve fazer parte da revisão?
  2. Você deve acompanhar o feedback?

Na minha experiência, incluindo o autor do trabalho é essencial .

  • O autor terá a oportunidade de participar do e aprender de qualquer discussão que acontecer.
  • O autor provavelmente é mais adequado para resolver quaisquer defeitos encontrados no trabalho; se eles receberem apenas uma lista de itens de ação sem estarem presentes para a revisão, eles perderão o contexto de qualquer discussão.
  • O autor pode ser chamado para defender a maneira como um artefato foi escrito.

Quanto ao acompanhamento do feedback da análise: Sim , ele deve ser rastreado.

  • Dos itens encontrados, quais são problemas de treinamento?
  • Quais são as práticas recomendadas que devem ser seguidas para todo o trabalho futuro?
  • Quais defeitos foram defeitos porque o código é difícil de ler, está mal documentado etc.?
  • Quais defeitos falam sobre problemas maiores que exigem mais trabalho do que uma resposta à inspeção - eles devem ser melhor rastreados como tickets de bugs distintos a serem trabalhados, conforme os recursos permitirem?

Você tem planos de obter conformidade com CMMI de qualquer tipo?

  • Você deseja acompanhar todos os defeitos encontrados e o fato de que cada um deles foi resolvido.

Seu cliente ou contrato exige que todo o código seja revisado?

  • Você deseja acompanhar os problemas e os materiais de inspeção para poder responder "SIM" e demonstrar isso, se necessário.
por 05.01.2012 / 18:10
fonte
1

Minha opinião sobre um processo de revisão de código.

Primeiro, existem duas regras básicas:

  1. ninguém pode confirmar código não revisado
  2. ninguém pode rever uma alteração que contribuiu para

eu. Quando um colega está prestes a cometer uma mudança, nos sentamos juntos e

  • verifique se todos os casos de teste são verdes em seu computador
  • verifique se ela escreveu / modificou os casos de teste
  • verifique se o código dele corresponde à diretriz de codificação existente
  • verifique as alterações dele e concentre-se na lista das 25 de Jeff Atwood
  • analisamos as alterações dela e discutimos

Esta é uma verificação rápida, pode ser feita em 5 minutos. É uma boa maneira de obter um feedback rápido, aprender sobre a nova mudança e nada é quebrado

II. O desenvolvedor sênior / líder de equipe deve selecionar os compromissos diariamente e revisá-los completamente e compartilhar seus pensamentos e descobertas com a equipe (eles devem implementar as descobertas que escreveram o código errado)

III. durante a retrospectiva (se tiver alguma), verifique o código do outro para aprender

Eu escrevi sobre o tópico aqui e here .

    
por 04.01.2012 / 00:22
fonte