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

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?

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.

É 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.

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".