Qual é o objetivo de uma Revisão de Código

76

Estou tentando vender minha organização pelo valor das revisões de código. Eu trabalhei em vários lugares onde eles estavam empregados. Eu os vi acostumados a escolher escolhas de estilo e decisões funcionais, e os vi usados como nada mais que uma verificação do intestino para garantir que nada de perigoso esteja sendo implementado. Minha intuição é que o objetivo mais eficaz está em algum lugar entre as duas opções.

Então, qual é o objetivo de uma revisão de código?

code-reviews theory

— SoylentGray
fonte

16

Relacionado (no estouro de pilha): O objetivo das revisões de código #

— yannis

16

- Como você saberia se tivesse escrito código legível e de fácil manutenção? - Seu colega avisa depois de revisar o código. Justificativa: Você não pode determinar isso sozinho, porque sabe mais como autor do que o código diz por si só. Um computador não pode lhe dizer, pelas mesmas razões que não pode dizer se uma pintura é arte ou não. Portanto, você precisa de outro ser humano - capaz de manter o software - para examinar o que escreveu e dar sua opinião. O nome formal desse processo é "Revisão por pares" .

— mosquito

3

"Qual é o objetivo de uma revisão de código?" para impedir que os desenvolvedores escrevam código terribad e orientá-los na direção certa.

— precisa saber é o seguinte

7

Parece Code Review pode ter uma resposta indireta a esta pergunta .. basta navegar nas perguntas e respostas lá, o fim de uma revisão de código se torna muito aparente :)

— Mathieu Guindon

3

Gostaria de saber quantas vezes os programadores descobriram bugs em seu próprio código apenas através do simples processo de explicar seu código durante uma revisão?

— hatchet-inactive

75

Há várias razões pelas quais você deseja realizar uma revisão de código:

Educação de outros desenvolvedores. Certifique-se de que todos vejam a modificação associada a uma correção ou aprimoramento de defeitos, para que possam entender o restante do software. Isso é especialmente útil quando as pessoas estão trabalhando em componentes que precisam ser integrados ou em sistemas complexos, nos quais uma pessoa pode passar longos períodos sem observar determinados módulos.
Localização de defeitos ou oportunidades de melhoria. Tanto o código de entrega quanto o código e os dados de teste podem ser examinados para encontrar pontos fracos. Isso garante que o código de teste seja robusto e válido e que o design e a implementação sejam consistentes em todo o aplicativo. Se for necessário fazer alterações adicionais, a oportunidade será mais próxima do ponto de entrada.

Existem vários casos de negócios para conduzir revisões:

Encontrar defeitos ou problemas que precisariam ser retrabalhados mais perto da injeção. Isso é mais barato.
Conhecimento compartilhado do sistema e treinamento cruzado. Menos tempo para que um desenvolvedor acelere para fazer alterações.
Identificação de possíveis aprimoramentos no sistema.
Abrindo a implementação para garantir que os testadores estejam fornecendo cobertura adequada. Transformando uma caixa preta em uma caixa cinza ou branca a partir de uma perspectiva de teste.

Se você estiver procurando por uma discussão abrangente sobre os benefícios e estratégias de implementação das revisões por pares, recomendo verificar as Revisões por pares em Software: um guia prático de Karl Wiegers .

— Thomas Owens
fonte

7

+1, acho que você identificou bem os pontos principais, com as prioridades corretas. Manter o design consistente ao lidar com colegas de trabalho que constantemente encontram soluções "WTF" muito criativas só podem ser alcançadas por revisões regulares de código.

— Doc Brown

Fazemos revisões de código em nosso código JavaScript, principalmente para garantir que os desenvolvedores cumpram os padrões descritos, usando o padrão estabelecido ao projetar módulos, usando os componentes fornecidos e não iniciando a codificação ninja (intencionalmente ou não) em torno de problemas que já temos soluções para. Eles também são ótimos para identificar alguém que acidentalmente sobrescreveu o thiscontexto, não o usou .hasOwnPropertynos locais em que deveria estar, etc., etc. - Então, principalmente para os padrões. Em um idioma gerenciado como o C #, é claro que você tem vários motivos menos que os idiomas dinâmicos.

— Nope

1

Até agora, sua resposta apenas alude a melhorias na correção do código. Ele falha em abordar a legibilidade / manutenção do código, que raramente pode ser quantificado com precisão pelo desenvolvedor em desenvolvimento.

— ArTs

51

Revisões de código são uma ferramenta para transferência de conhecimento .

Quando os desenvolvedores revisam o código um do outro, eles adquirem familiaridade em todas as áreas do sistema. Isso reduz o fator de barramento de um projeto e torna os desenvolvedores mais eficientes quando precisam fazer manutenção em uma parte do sistema que eles não escreveram.
Quando um programador júnior revisa o código de um sênior, o programador júnior pode aprender truques que, de outro modo, só serão aprendidos através da experiência. Isso também pode funcionar como um corretivo em relação a códigos excessivamente complicados.

Uma revisão completa do código exigirá verificações frequentes em várias documentações. É uma ótima maneira de aprender um idioma ou API.
Quando um programador sênior analisa o código de um júnior, esta é uma oportunidade para resolver problemas antes que eles se convertam em dívida técnica. Uma revisão de código pode ser uma boa configuração para orientar programadores juniores.

As revisões de código não são sobre:

... encontrando bugs. É para isso que servem os testes. Ainda ocorrerá frequentemente que uma revisão de código encontra algum problema.
… Escolhendo questões de estilo - aceite um estilo e use formatadores automáticos para aplicá-lo. Mas há muitas coisas que uma ferramenta automatizada não pode verificar. As revisões de código são um bom local para garantir que o código esteja suficientemente documentado ou se auto-documente.

— amon
fonte

2

seu último ponto sobre questões de estilo de nitpicking com as quais não concordo totalmente - acabamos de ter uma experiência angustiante ao revisar o código de um desenvolvedor júnior e a queixa mais flagrante foi realmente sobre estilo, mas não os tipos de problemas de estilo que são facilmente programaticamente forçado .... waaaaaay demais if declarações para edgecases etc; problemas que sim, você pode fazer com que um computador encontre em alguns casos, mas a maioria não era um problema que valha a pena encontrar genericamente por script. Demora 30 segundos de leitura para começarmos a vê-lo, outros 30 para explicar ao desenvolvedor e, espero, corrigir o problema. Ainda em estado de choque: /

— pacifist

7

@ pacifista Esse não é o tipo de estilo que o atendente está descrevendo. Estilo é sobre locais de chaves, recuo e assim por diante. Se seu desenvolvedor júnior estiver usando muitas declarações if, você terá um problema totalmente diferente do estilo; um atributo geral da codificação STYLE é que não afeta o desempenho. E acho que uma quantidade significativa de declarações if afetará o desempenho.

— Pimgd

12

Ao fazer uma revisão, muitas vezes identifico coisas em que penso "isso parece um bug", depois escrevo um caso de teste específico para provar que é um bug. Portanto, um dos muitos objetivos das análises de código é encontrar bugs. É por isso que acho que o ponto de vista "revisão de código ou testes" é um pouco demais.

— Doc Brown

2

Além do @DocBrown, existem casos que não podem ser facilmente testados - corridas de dados, alguns tipos de deadlocks, livelocks, comportamentos / valores indefinidos (principalmente em C / C ++, mas a ordem dos elementos nas tabelas de hash indefinidas também) ou no uso de recursos (abrir um arquivo em um loop pode ser uma má ideia, mesmo com o GC). Algumas dessas coisas podem ser detectadas pela análise estática -compilador-suficientemente inteligente .

— Maciej Piechotka

2

@pacifist, seu exemplo específico seria totalmente criticado em uma revisão de código. Também seria uma bandeira vermelha para qualquer analisador de código estático (complexidade ciclomática 17!). Uma revisão de código identificaria rapidamente essa função como um problema no estilo semântico (ou mesmo no algoritmo!). Contudo. Esse tipo de problema não é apenas um problema de "estilo". Se você tratá-lo como tal, terá em breve algum código realmente desagradável no seu repositório; é apenas "estilo", afinal.

— Pimgd

12

A coisa mais valiosa que recebo pessoalmente de uma revisão de código é a confiança de que o código é claro para outra pessoa. As variáveis estão claramente nomeadas? O objetivo de cada pedaço de código é razoavelmente óbvio? Alguma coisa ambígua foi esclarecida com um comentário? Os casos extremos e os valores válidos para os parâmetros são descritos nos comentários e verificados no código?

2

este não parece oferecer nada substancial sobre anteriores 4 respostas

— mosquito

2

@gnat: As outras respostas abordam a transferência de conhecimento e a detecção de bugs. Isso é importante, mas há mais em uma revisão de código.

1

até onde sei, há mais parte razoavelmente abordada nesta resposta : "Se você estiver procurando por uma discussão abrangente sobre os benefícios e estratégias de implementação das revisões por pares, recomendo verificar as Revisões por pares no software: Um guia prático de Karl Wiegers. " Essa resposta também cobre: "um corretivo contra códigos muito complicada"

— mosquito

2

@gnat Ele enfatiza um aspecto diferente dos pontos levantados em outras respostas. Você já ficou intrigado com seu próprio código que escreveu há seis meses? A revisão de código permite acelerar esse processo. Se o seu colega estiver intrigado com o seu código, você ainda poderá esclarecê-lo enquanto o problema ainda estiver em sua memória.

— 200_success 11/09/14

1

@ 200_success talvez. Mas esse ponto, se estiver realmente presente, parece realmente mal apresentado. Até o seu comentário consegue comunicá-lo melhor do que esta "resposta". Sem mencionar que ele apenas repete o que foi apontado em um comentário anterior que se refere a resposta canônica explicar isso em uma questão relacionada

— mosquito

7

Gostaria de adicionar duas áreas não cobertas pelas outras ótimas respostas:

Um ótimo motivo para a revisão de código é o efeito Hawthorne, que no nosso caso se traduz em: Se você sabe que alguém analisará seu código posteriormente, é muito mais provável que você o escreva melhor em primeiro lugar.

Outro ótimo motivo é para melhores práticas de desenvolvimento seguras. É necessário apenas olhar para o goto fail da Apple (uma linha de código duplicada acidental) ou o bug Heartbleed (uma falha básica na validação de entrada) para entender a importância de análises de código apropriadas em um ciclo de vida de desenvolvimento seguro.

— Chris Knight
fonte