7 maneiras de reduzir drasticamente seu tempo na revisão de código
As revisões de código podem ser complicadas. Explore 7 práticas recomendadas para tornar o processo de revisão de código uma experiência melhor tanto para o autor do código como para o revisor de código.
1: Mantenha as solicitações de pull pequenas
Todo engenheiro teme revisar pull requests que tenham mais de 1.000 linhas de código alteradas. Essas revisões podem levar horas para serem concluídas e, muitas vezes, o que acaba acontecendo é que o revisor começa a examinar o código em vez de revisá-lo cuidadosamente.
A solução é manter seus pull requests pequenos. Pequenos PRs são mais fáceis e rápidos de revisar porque o revisor não precisa gastar tanto tempo construindo um modelo mental de como todas as mudanças funcionam juntas. Manter seus PRs pequenos pode parecer difícil no começo, mas pode ser feito se você dividir seu trabalho em pequenas tarefas e manter o foco. Não faça grandes refatorações ao mesmo tempo em que implementa novos recursos ou corrige bugs. Use sinalizadores de recurso em seu código para que você possa mesclar pequenas partes de novos recursos no branch master sem que ele apareça no aplicativo de produção.
2: Use modelos de solicitação pull
Outro aborrecimento é ser solicitado a revisar um pull request sem nenhum contexto. Um modelo de solicitação pull é um formulário pequeno e configurável que você pode definir como o texto padrão em cada nova solicitação pull.
Bons modelos de relações públicas geralmente incluem uma pequena lista de verificação para o autor do código passar para garantir que eles não tenham perdido nenhum dos princípios básicos. Essa lista de verificação pode incluir itens como testes de unidade, documentos, internacionalização, suporte entre navegadores e acessibilidade.
3: Implementar SLAs de tempo de resposta.
Ao escolher um SLA de tempo de resposta (contrato de nível de serviço), você encontrará o equilíbrio certo. É interessante ter um SLA de tempo de resposta de duas horas para PRs de equipes internas e um SLA de tempo de resposta de 24 horas para PRs de equipes externas.
Independentemente do que você e seus colegas de equipe decidirem, ter um acordo de equipe permite que você responsabilize um e outro.
4: Treinar Engenheiros Júnior e Médio
As oportunidades de treinamento estão em toda parte. Mentorar engenheiros menos experientes inclui mais do que apenas ensiná-los sobre as tecnologias e linguagens com as quais estão trabalhando. Também inclui o ensino de soft skills, como fazer uma revisão de código eficaz.
Existem muitos recursos excelentes sobre como ser um revisor de código mais eficaz. Vale a pena ler o Guia do desenvolvedor de revisão de código do Google na íntegra. O guia tem excelentes conselhos tanto para o autor do código quanto para o revisor do código.
5: Configure pipelines de integração contínua
Deixe os computadores automatizarem as coisas triviais para que você possa se concentrar nas coisas importantes que exigem um ser humano.
Para projetos JavaScript, é simples configurar um formatador como Prettier e um linter como ESLint para seu repositório. Você pode então configurar a integração contínua para seu repositório usando algo como Travis CI. CircleCI, GitHub Actions ou GitLab CI/CD.
Seu pipeline de CI executará essas tarefas de formatação e linting para você junto com seus testes de unidade. Se o pipeline de CI falhar em qualquer etapa de uma solicitação pull, ele impedirá que essa solicitação pull seja mesclada.
6: Use aplicativos de revisão de solicitação pull
Às vezes, é necessário não apenas revisar o código em uma solicitação pull, mas também visualizar manualmente as alterações no aplicativo para verificar se as coisas estão boas. Para aplicativos com etapas de configuração complexas, extrair o código de outra pessoa e executá-lo localmente em sua máquina pode levar de cinco minutos a uma hora. Que dor de cabeça!
Os aplicativos de revisão de solicitação pull são usados para implantar automaticamente seu código em um ambiente de teste de curta duração sempre que um novo PR é criado. Isso permite que os revisores inspecionem facilmente as alterações da interface do usuário sem precisar baixar o código e executá-lo localmente em sua máquina. Isso não apenas economiza tempo, mas também estimula os revisores a serem mais completos em suas revisões, facilitando o processo.
7: Gere diagramas para visualizar suas alterações de código
Ao revisar o código no GitHub ou no GitLab, os arquivos geralmente são mostrados em ordem alfabética. Para PRs relativamente pequenos, isso pode não ser um problema. Mas quando há dezenas de arquivos envolvidos em um PR, às vezes é útil ver essas alterações agrupadas logicamente para que você possa ver como elas se encaixam em uma imagem maior.
Os Mapas de Revisão CodeSee ajudam você a visualizar quais arquivos foram alterados e como essas alterações afetam suas dependências upstream e downstream. Eles se integram ao GitHub para postar automaticamente um comentário e um diagrama em seu PR. Você pode até criar tours interativos de seu código para ajudar a orientar seus revisores de código. O melhor de tudo é que o CodeSee Maps é gratuito para organizações de código aberto e seus repositórios públicos.
