Como fazer melhores análises de código quando as solicitações pull são grandes?

Isenção de responsabilidade: existem algumas perguntas semelhantes, mas não encontrei nenhuma que abordasse especificamente os problemas que você enfrenta ao analisar uma grande solicitação de recebimento.

Problema

Eu sinto que minhas revisões de código poderiam ser feitas de uma maneira melhor. Estou falando particularmente de grandes revisões de código com muitas alterações em mais de 20 arquivos.

É muito simples detectar problemas óbvios de código local. Porém, entender se o código atende aos critérios de negócios é uma história diferente.

Tenho problemas após o processo de pensamento do autor do código. É muito difícil quando as alterações são numerosas e se espalham por vários arquivos. Tento me concentrar nos grupos de arquivos relacionados a uma parte específica das alterações. Em seguida, revise os grupos, um por um. Infelizmente, a ferramenta que eu uso (Atlassian Bitbucket) não é muito útil. Sempre que visito um arquivo, ele é marcado como visto, mesmo que muitas vezes não esteja relacionado à parte das alterações atualmente examinadas. Sem mencionar que alguns arquivos devem ser visitados várias vezes e suas alterações revisadas peça por peça. Também não é fácil voltar aos arquivos relevantes quando você segue um caminho ruim.

Possíveis soluções e por que elas não funcionam para mim

A revisão de uma solicitação pull por confirmações geralmente resolve os problemas de tamanho, mas eu não gosto disso, pois frequentemente observarei alterações desatualizadas.

Obviamente, criar solicitações pull menores parece um remédio, mas é o que é, às vezes você recebe uma solicitação pull grande e precisa ser revisada.

Você também pode ignorar o aspecto lógico do código como um todo, mas parece bastante arriscado, principalmente quando o código vem de um programador inexperiente.

Usar uma ferramenta melhor poderia ser útil, mas não encontrei uma.

Questões

• Você tem problemas semelhantes com suas revisões de código? Como você os enfrenta?
• Talvez você tenha ferramentas melhores?

Tivemos esses problemas e a pergunta abaixo tem funcionado bem para nós:

O PR faz algo que pode ser mesclado e pode ser testado independentemente?

Tentamos quebrar PRs por responsabilidade única (SR). Após o empurrão inicial, as pessoas ficaram surpresas ao descobrir que mesmo algo pequeno, embora único, pode ser grande.

O SR facilita muito a revisão e também divulga o conhecimento da implementação esperada.

Isso também permite refatores incrementais à medida que mais é adicionado e o tempo de resposta de PR é drasticamente reduzido!

Eu sugiro dividi-los pela SR, se possível, e ver se funciona para você. É preciso alguma prática para fazer dessa maneira.

Às vezes, você não pode evitar grandes solicitações de recebimento - mas pode discernir quem tem que responsabilidade.

Trato solicitações pull como argumentos persuasivos. O autor está tentando me convencer de que o código deve parecer e funcionar dessa maneira.

Como em qualquer argumento, ele deve ter uma única ideia clara. Também é:

• um refator,
• uma otimização,
• ou nova funcionalidade.

Se eles não estão sendo claros, há uma boa chance de eles não entenderem eles mesmos. Abra o diálogo e ajude-os a dividir seus argumentos em seus sub-argumentos. Se necessário, está perfeitamente correto - até benéfico para eles recriarem esses commits e oferecer solicitações de recebimento mais abrangentes e diretas.

Ainda haverá grandes solicitações de recebimento, mas com um argumento claro é muito mais fácil ver o que não se encaixa.

Quanto às ferramentas, isso depende da sua organização e processo. O BitBucket é uma ferramenta decente, seja ela melhor ou não, depende de tudo, desde seu orçamento, hardware, requisitos até processos preexistentes, regras de negócios e várias adaptações de software que você já fez para acomodar o BitBucket. Eu começaria examinando a documentação para ver se o comportamento pode ser configurado, talvez jogando para a comunidade de plug-ins (ou ingressando nele criando um plug-in para fazer isso).

Não revise a solicitação pull completa, mas todas as confirmações. Você adquirirá uma melhor compreensão da solicitação de recebimento de qualquer maneira, fazendo-o desta maneira.

Se as confirmações forem pequenas, fazer essa revisão não deve ser um problema. Você segue as alterações uma a uma através das confirmações e acaba obtendo a imagem completa. Existem inconvenientes, como o fato de você às vezes revisar alterações que serão desfeitas alguns commits mais tarde, mas isso não deve ser muito.

Se as confirmações forem grandes, discuta-as com a pessoa que as fez. Explique-lhe por que grandes confirmações são problemáticas. Ouça os argumentos da outra pessoa sobre por que ele comete alterações raramente: você pode aprender, por exemplo, que ele evita fazer confirmações porque os ganchos de pré-confirmação demoram muito tempo; nesse caso, esse problema deve ser resolvido primeiro.

A revisão de uma solicitação pull por confirmações geralmente resolve os problemas de tamanho, mas eu não gosto disso, pois frequentemente observarei alterações desatualizadas.

Você sabe, mas esse é um problema menor e você deve gastar muito menos tempo revisando o código, que será desfeito alguns commits mais tarde do que o tempo que você perde tentando descobrir por que o código foi alterado ao revisar um único arquivo.

“Frequentemente” é vago, mas se você passar muito tempo revisando o código que não encontrou o caminho para a revisão final da solicitação de recebimento, você pode usar duas técnicas:

• Percorra rapidamente todas as confirmações uma vez, apenas lendo as mensagens de confirmação. Dessa forma, ao estudar um commit em particular, você deve se lembrar de que uma mensagem de commit em algum lugar mais tarde dizia que a alteração que você estava vendo foi revertida.

• Tenha uma visão lado a lado da versão mais recente do arquivo (embora em muitos casos, para confirmações grandes, (1) os arquivos possam ser radicalmente diferentes e (2) os arquivos possam ser renomeados ou os grandes blocos de código possam ser movido para outro lugar, dificultando a localização do arquivo correspondente).

• Peça aos committers para esmagar as confirmações quando fizer sentido ou tenha uma convenção de mensagens de confirmação específica em que uma confirmação desfaz parte de outra e faça sua revisão levando em consideração várias confirmações a seguir.

^{Por exemplo, imagine que você está vendo um arquivo em que alguma variável foi renomeada. O que isso diz a você? Como você deve revisar essa alteração? Se você estivesse revisando o commit por commit, no entanto, veria que um único commit renomeou a mesma variável em vinte arquivos, e o comentário indica que o nome foi alterado para usar o termo comercial apropriado. Essa alteração faz todo o sentido e é possível revisar.}

Elabore o que você está tentando alcançar com revisões de solicitações de recebimento e veja se há uma alternativa.

Por exemplo, você pode querer

• Garantir que os padrões sejam seguidos
• Verifique se a funcionalidade está correta
• Verifique se mais de uma pessoa entende o código
• Treinar juniores

etc etc.

Algumas delas podem ser melhor atendidas por outras coisas, e até mesmo entender as razões permite limitar o escopo de suas verificações.

Por exemplo, se estou verificando todas as linhas para poder sugerir e discutir alterações no treinamento, posso pular isso em um grande PRs feito por idosos

Se eu precisar entender o código, talvez emparelhe a programação em recursos grandes e limite a revisão do código a uma verificação de padrões.

Você não precisa verificar todas as coisas em cada RP, desde que tenha uma abordagem em camadas do controle de qualidade