quantidade de código na revisão de código

8

Na minha experiência, a maioria das equipes da empresa revisa o código do membro da equipe com uma pequena quantidade de código, sempre com menos de centenas de linhas. É apropriado revisar grande quantidade de código, por exemplo, um módulo, quando o código estiver completo e pronto para ser revisado de uma vez por todas?

code-reviews upton
fonte
5
Relacionado (e possivelmente duplicado): O que contém uma revisão de código padrão? , Como escolho qual código revisar? & Devemos tentar revisar todo o nosso código?
yannis
1
Sua pergunta implica revisar "de uma só vez". Não há nada a dizer que um módulo grande não poderia ser dividido em sessões de revisão menores.

Respostas:

8

A razão para as pequenas revisões de código é maximizar a eficácia.

Estudos envolvendo o processo de software pessoal descobriram que os revisores são mais eficazes no que diz respeito à maximização de defeitos identificados na revisão, quando revisam não mais que 150-200 linhas de código fonte por hora. Dados esses dados empíricos, torna-se uma questão de determinar por quanto tempo as pessoas podem ficar atentas. Não tenho dados empíricos, mas sei que minha mente começa a vagar após cerca de 1 hora lendo alguma coisa. Para mim, isso indica que as revisões de código devem revisar menos de 150 linhas de código por vez.

Thomas Owens
fonte
Provavelmente levaria mais de uma hora para revisar corretamente 200 novas linhas de código. Bem, talvez o código Java seja menos conciso que, digamos, Ruby ou Python, mas eu prefiro fortemente listas de alterações com <50 linhas alteradas severamente. Eles podem ser revisados ​​rapidamente, e com menos risco de perder um bug em potencial.
9000
@ 9000 Depende do seu nível de revisão. Uma inspeção formal em que cada linha é lida é muito mais lenta do que uma verificação na mesa onde um desenvolvedor individual lê no seu próprio ritmo. A familiaridade com a linguagem de programação e o sistema em desenvolvimento também tem impacto. As 150-200 linhas / hora são um limite superior. Pessoalmente, acho que leio o código entre 80 e 100 linhas por hora ao compreendê-lo e determinar como ele se encaixa no sistema.
Thomas Owens
4

É apropriado se ajudar sua equipe a criar um produto melhor.

Alguns motivos pelos quais as revisões de código geralmente se concentram em partes menores:

  • A revisão adequada de uma grande quantidade de código exige que cada participante gaste muito tempo se preparando, e isso pode ser caro.

  • Quanto mais longa a reunião de revisão (qualquer reunião, na verdade), menos pessoas prestam atenção. Duas horas é o máximo que a maioria das pessoas aguenta, e manter as reuniões mais curtas do que isso (digamos, uma hora ou 90 minutos no máximo) ajuda muito a garantir que todos estejam no seu melhor.

  • Muitas vezes, não é necessário revisar todas as linhas. Um motivo para revisar o código é garantir que todos sigam basicamente o mesmo conjunto de diretrizes de codificação. Uma revisão detalhada de uma quantidade menor de código funciona melhor para esse propósito do que uma revisão menos detalhada de mais código.

Dito isto, se você acha que revisar mais código é útil e se sua equipe aguenta, tente de qualquer maneira. Isso ajudará a garantir que haja algumas regras básicas e que alguém atue como facilitador para manter a reunião em andamento. Além disso, considere pedir que os revisores enviem seus comentários antecipadamente, para que você gaste menos tempo em assuntos específicos, como uso inadequado do espaço em branco e mais tempo discutindo questões importantes e interessantes.

Caleb
fonte
1
Algo a se notar é que os dois primeiros pontos se aplicam apenas a inspeções formais. Uma verificação de mesa no lazer de outro desenvolvedor não exige preparação formal (se estiver familiarizado com o sistema em desenvolvimento) nem exige uma reunião.
Thomas Owens
@ThomasOwens Agreed. Felizmente, uma verificação informal também será menor que centenas de linhas.
Caleb
2

Se você revisar uma grande quantidade de código quando já estiver completo (e presumivelmente funcional), isso se tornará mais uma sessão de "deveríamos ter feito ..." do que "vamos corrigir / alterar isso para fazer ..."

Portanto, se o objetivo principal da atividade é como um exercício de aprendizado post-mortem, a grande revisão de código faz sentido. Se tentar detectar defeitos, provavelmente não funcionará muito bem. É provável que pequenos defeitos sejam esquecidos, já que todos na revisão ficam entediados e cansados, e grandes defeitos estruturais provavelmente serão ignorados, pois, bem, "tarde demais agora - o código está escrito e o cliente o quer ontem".

Erik Dietrich
fonte
+1 por precisar identificar o objetivo da revisão.
precisa