As revisões de código podem ser dolorosas. Os engenheiros de software geralmente reclamam que o processo de revisão é lento, atrasa as tarefas de downstream e leva à troca de contexto conforme você navega entre uma solicitação pull aberta (PR) e sua próxima tarefa. As revisões de código também podem ser cheias de picuinhas e troca de bicicletas, tornando-se uma experiência ruim para todos os envolvidos. Para remediar esse problema, alguns engenheiros chegaram a sugerir que eliminemos totalmente as solicitações pull e as revisões de código. Embora isso possa funcionar para pequenas equipes em startups, não acho que essa seja a solução certa para todos, especialmente para empresas de nível empresarial. Em vez disso, há várias maneiras de tornar o processo de revisão de código uma experiência melhor para o autor e para o revisor do código. Vamos considerar sete dessas práticas recomendadas juntos. Nº 1: mantenha as solicitações pull pequenas Todo engenheiro teme revisar solicitações de pull com 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 suas solicitações pull pequenas. PRs pequenos 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. Há também menos código alterado, o que, com sorte, equivale a menos erros, menos comentários e menos rodadas de idas e vindas entre o autor e o revisor. 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 poder mesclar pequenas partes de novos recursos na ramificação principal sem que ela apareça no aplicativo de produção. Mantenha seus PRs pequenos. Seus revisores ficarão gratos. Nº 2: Use modelos de pull request Outro aborrecimento é ser solicitado a revisar uma solicitação pull sem nenhum contexto. Quando um RP cai em seu colo sem nenhuma explicação, muitas vezes você fica se perguntando: “Para que serve esse RP? Que problema isso está resolvendo? Existe uma tarefa relacionada para isso? Por que essa abordagem específica foi adotada?” Um é um formulário pequeno e configurável que você pode definir como o texto padrão em cada nova pull request. O modelo PR solicita que o autor do código forneça detalhes relevantes para seu PR. Normalmente, um modelo de RP solicita uma breve descrição do que você fez e por quê, um link para o tíquete de tarefa e um plano de teste para validar as alterações. modelo de pull request Bons modelos de relações públicas geralmente também incluem uma pequena lista de verificação para o autor do código verificar para garantir que não tenha 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. Abaixo está um modelo de pull request de exemplo que gosto de usar para todos os meus repositórios: Nº 3: implemente SLAs de tempo de resposta Se você perceber que as pull requests ficam sem revisão por mais tempo do que você gostaria, agora é um bom momento para definir as expectativas em equipe sobre a rapidez com que uma nova pull request deve ser revisada. Em outras palavras, qual é a quantidade máxima de tempo que um PR pode existir antes de ser coletado? Uma hora? Duas horas? 24 horas? Sua resposta a essa pergunta provavelmente dependerá do tamanho de sua equipe. Você também pode ter uma resposta diferente para pull requests internos de sua equipe versus pull requests externos de outras equipes. Ao escolher um SLA (acordo de nível de serviço) de tempo de resposta, você deve encontrar o equilíbrio certo. Não é razoável esperar que todos abandonem imediatamente o que estão fazendo e revisem seu código quando você postar um novo PR, mas você também não quer que os PRs fiquem sem revisão por horas a fio. Encontre o equilíbrio certo que permita que seus colegas de equipe entrem em um estado de fluxo. Eles devem ser capazes de trabalhar em seu próprio código e, em seguida, revisar os PRs em pontos de parada naturais ao longo do dia. Pessoalmente, gosto de ter um SLA de tempo de resposta de duas horas para PRs de equipe interna e um SLA de tempo de resposta de 24 horas para PRs de equipe externa. Independentemente do que você e seus colegas de equipe decidam, ter um acordo de equipe permite que vocês responsabilizem um ao outro. Se todos concordaram com um SLA específico e esse tempo já passou para um de seus PRs, você sabe que não há problema em começar a incomodar as pessoas sobre isso. Nº 4: Treine engenheiros juniores e de nível médio As oportunidades de treinamento estão por toda parte. Orientar engenheiros menos experientes inclui mais do que apenas ensiná-los sobre as tecnologias e linguagens com as quais estão trabalhando. Também inclui ensinar a eles habilidades interpessoais, como fazer uma revisão de código eficaz. Ensine a seus colegas de equipe o que você procura durante uma revisão de código. Ajude-os a entender o que é importante e o que não é. Ensine-os a se comunicar de forma eficaz em seus , como prefixando sugestões sem bloqueio com "nit". comentários de revisão de código Existem muitos recursos excelentes sobre como ser um revisor de código mais eficaz. Vale a pena ler o do Google na íntegra. O guia oferece excelentes conselhos tanto para o autor do código quanto para o revisor do código. Para um recurso mais atrevido, é facilmente um dos melhores (e divertidos) conselhos para desenvolvedores que criam solicitações pull. Guia do desenvolvedor de revisão de código Como fazer seu revisor de código se apaixonar por você Nº 5: Configurar pipelines de integração contínua As revisões de código tornam-se tediosas quando a maioria dos comentários são coisas como “Falta ponto-e-vírgula” ou “Recuo parece errado aqui”. Não gaste tempo durante as revisões de código em coisas que os formatadores de código e os linters de código podem cuidar para você. 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 o e um linter como o para o seu repositório. Você pode configurar a integração contínua para seu repositório usando algo como , , ou . Prettier ESLint Travis CI CircleCI GitHub Actions 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 a solicitação pull seja mesclada. Agora, você automatizou várias partes importantes da revisão do código, economizando horas. Nº 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 tudo está bem. Para aplicativos com etapas de configuração complexas, baixar 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! 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 incentiva os revisores a serem mais minuciosos em suas revisões, tornando-o mais fácil. Os aplicativos de revisão de solicitação pull Nº 7: Gere diagramas para visualizar suas alterações de código Ao revisar o código no GitHub ou 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. ajudam 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. Os mapas de revisão do CodeSee Conclusão: 7 maneiras de reduzir drasticamente seu tempo na revisão de código Para recapitular, aqui estão sete dicas para reduzir drasticamente seu tempo na revisão de código: Mantenha as solicitações pull pequenas. Use modelos de pull request para fornecer todo o contexto de que um revisor precisa. Implemente SLAs de tempo de resposta. Treine engenheiros de nível júnior e intermediário nas principais coisas que você procura durante uma revisão de código. Configure pipelines de CI para executar linters, formatadores e testes de unidade. Use aplicativos de revisão de pull request para que você possa inspecionar facilmente as alterações da interface do usuário. Gere diagramas para visualizar suas alterações de código usando uma ferramenta como CodeSee Review Maps. Obrigado pela leitura e codificação feliz! Também publicado aqui
