As análises de código analfabeto reduzem significativamente o fluxo de trabalho. Quando um grande número de alterações fica paralisado por alguns dias (ou semanas!), A liberação do produto no mercado terá que ser adiada. Aqui estão algumas razões pelas quais isso acontece:

Não há design de código padrão
Nenhuma verificação automatizada usada
Os programadores não analisam independentemente seu código.
Solicitações de piscina enormes
Solicitações de piscina vagas
Prazos ausentes para revisão de código

Não há design de código padrão

Cada equipe deve adotar um padrão de formato de código (padrão de programação, guia de estilo), com o qual todos concordam. Inclui convenções de nomenclatura, estrutura de pastas, formatação de código e uma lista de práticas recomendadas, como teste de unidade, validação etc.

A falta de um padrão claro e de convenções força todo desenvolvedor a escrever o código como quiser, o que leva a disputas de código. -Reveja. Se você receber muitos comentários sobre formatação, convenções de nomenclatura e muito mais, é hora de falar sobre um padrão comum.

Sua equipe pode desenvolver seu próprio conjunto de recomendações ou começar com recomendações conhecidas de outras empresas. Aqui está um exemplo do Google .

Nenhuma verificação automatizada usada

Após adotar os padrões de código, aprenda as ferramentas para verificar a conformidade com esses padrões. Para quase todos os idiomas, existem ferramentas para formatar códigos, linters e outros utilitários que você pode colocar em ganchos antes de confirmar e registrar nos sistemas de CI / CD.

Essas ferramentas verificam o código quanto à conformidade com os padrões de design e notificam o autor de violações. O autor tem a oportunidade de corrigir problemas antes de enviar uma solicitação de pool, o que reduz significativamente o ruído. Quanto mais verificações passarem automaticamente, mais tempo o revisor terá para se concentrar em problemas mais sérios, como falhas na arquitetura, falhas na implementação etc.

Os programadores não analisam independentemente seu código.

Antes de entrar em contato com colegas para uma revisão de código, o autor deve revisar suas próprias alterações. É como verificar o texto de uma carta quanto a erros de digitação e antes de enviá-lo ao destinatário.

Na prática, validar seu próprio código é um desafio, porque você tende a inconscientemente pular falhas. Aqui estão algumas maneiras de melhorar a qualidade da auto-análise:

Faça uma solicitação de pool sem nomear revisores e retorne a ela após algumas horas para dar uma nova olhada em suas edições.
Suprima sua tendência natural de passar por mudanças e, em vez disso, observe-as intencionalmente linha por linha.
Siga a lista de verificação: O código está em conformidade com o padrão de design? Todos os requisitos de negócios são atendidos? existem testes para todos os casos de uso possíveis? etc.

Solicitações de piscina enormes

O número de comentários para a solicitação de pool é inversamente proporcional ao número de alterações contidas nele. Ou seja, um grande PR → poucos comentários, um pequeno PR → muitos comentários.

O fato é que os revisores não estudam cuidadosamente a solicitação de grande pool, mas tendem a rolar por ela para concluir o trabalho mais rapidamente. Isso é contrário ao objetivo de uma revisão de código. Às vezes, acontece o contrário quando o autor não recebe comentários por muitos dias, porque o revisor tem medo de começar a revisar demais as relações públicas.

Divida a solicitação de pool em pedaços menores que fazem sentido separadamente um do outro. Então você ajudará a considerá-los de maneira adequada e rápida.

Solicitações de piscina vagas

Muitas vezes, você recebe uma solicitação de pool com uma descrição vaga ou sem ela. O revisor deve entender o significado das mudanças, tentando lembrar a tarefa discutida em algum lugar da reunião ou no rastreador de erros. Portanto, é melhor fornecer ao PR informações de suporte:

Que mudanças ele contém
Com quais arquivos começar
Link para a tarefa no rastreador de erros
Capturas de tela se houver algum tipo de alteração visual

Essas informações fornecerão um contexto melhor para o revisor e, assim, agilizarão a revisão do código.

Prazos ausentes para revisão de código

Uma maneira de prolongar a revisão do código para sempre é não estabelecer prazos para o revisor. Defina prazos razoáveis, por exemplo:

O código de revisão deve ser concluído dentro de 48 horas a partir do momento do envio da solicitação de pool.
Para hotfixes, o período é de 30 minutos.

Obrigado pela leitura! :)

Como acelerar a revisão de código