CODE REVIEW

O que é Code Review

O Processo de Code Review (ou Revisão de Código) é uma iniciativa que visa melhorar a qualidade do código escrito nos nossos robôs. Basicamente ele é um processo onde os códigos serão revisados e ajustados antes de irem para produção.

O Code Review tem o objetivo de garantir que a qualidade do nosso código esteja de acordo com os padrões que estabelecemos, além de melhorar a capacitação de todos os nossos desenvolvedores. Em resumo, podemos lembrar que dois desenvolvedores pensam melhor do que um.

Este documento entrará em detalhes a respeito do processo de code review, como e quando ele será aplicado, além de reforçar as boas práticas e padrões que devem ser seguidos nos códigos escritos.

Branches de um Repositório

A estrutura dos projetos no Git vai ser alterada para novos projetos e reformulados. Todo projeto será composto de 3 branches:

• MASTER: Protegida A branch principal default de todo projeto do GitLab. Por motivos de backwards compatibility, sua funcionalidade permanece inalterada. Não iremos utilizar essa branch.

• RELEASE: Protegida A branch que vai conter o código de produção. A partir de agora ela estará protegida (mais detalhes a seguir).

• DEV: Não Protegida A branch padrão de desenvolvimento. A partir de agora, essa será a branch que deverá ser usada para fazer toda a parte de desenvolvimento e testes, ou seja, é a porta de entrada para todo código escrito nos projetos.

• QUALQUER OUTRA BRANCH: Não Protegida Dependendo da necessidade do usuário, podem ser criadas novas branches não protegidas que atuam da mesma forma que a DEV. O seu uso fica a critério de cada desenvolvedor (ex: Uma branch REFACTORING para conter o código referente a uma refatoração geral do projeto). Seu uso é opcional.

Branches protegidas e não protegidas:

Um conceito não necessariamente novo mas que será bem mais utilizado a partir de agora:

• Não Protegida:Essas branches não possuem restrições. Todo usuário com visibilidade do projeto poderá fazer pushes a ela.
• Protegida:As branches protegidas não aceitam nenhum tipo de push. Toda modificação feita a elas deve ser feita através de um **merge request** (que por sua vez, contém o processo de revisão de código). Como **merge requests** só podem ser feitos por usuários Maintainers, usuários Developers sozinhos não poderão atualizar código de branches protegidas. Isso é intencional e tem o objetivo de centralizar todas as mudanças que podem ocorrer em um projeto.

Merge request

Merge requests serão o novo ponto principal de mudanças. São uma forma de incorporar mudanças de uma branch para outra, como vemos no diagrama a seguir:

Por padrão, nenhum usuário poderá fazer commits diretamente a uma branch Protegida. Porém, **todo usuário** do repositório pode fazer commits a uma branch Não Protegida.

Para que as alterações possam ser propagadas de uma branch Não Protegida. para uma branch Protegida., o usuário deverá solicitar um Merge, através de um Merge Request. Um Merge é uma operação que vai incorporar as mudanças de uma branch (no nosso exemplo: Dev) em outra (no nosso exemplo: Release).

Uma vez solicitado o Merge Request, o usuário Developer deverá aguardar que um usuário Maintainer veja o Merge Request. O Maintainer. vai revisar o código (e solicitar mudanças, caso necessário) e então vai aprovar o Merge.

Uma vez aprovado o Merge, todas as alterações de Dev serão replicadas em Release.

Code Review

A parte principal do processo é o Code Review. Nessa etapa do processo, o código é revisado por um usuário Maintainer antes de ser aplicado em uma branch Protegida.

O processo de Code Review funciona com base em Comentários. Basicamente, o revisor vai olhar alguma parte do código que não ficou claro ou que ele visualiza uma falha ou inconformidade com os padrões acordados com a equipe e vai solicitar que o código seja alterado. Os comentários de um revisor podem começar com um prefixo, indicando o propósito do comentário:

• PRIO: Uma mudança que deve ser aplicada com prioridade. Geralmente alguma falha grave ou inconformidade que vai dificultar muito a manutenção do código futuramente. Devem ser tratadas com atenção.

• ALT: Uma solicitação para alterar o código. Tem um propósito semelhante ao PRIO, mas não é tão maléfico ao código.

• EXP: O revisor não conseguiu entender essa parte do código (e provavelmente outros desenvolvedores também podem ter dificuldade) e gostaria que você explicasse a sua linha de pensamento no código destacado.

• NIT: Uma mudança leve e pequena, com pouco impacto no código. Geralmente referente a organização de um arquivo, uma nomenclatura, ou algo parecido.

Você será notificado sempre que houver atualizações em relação a uma revisão de código. Também é interessante avisar ao revisor quando você precisar de uma revisão.

OBS: **NUNCA** ignore um comentário. Merge requests **não serão aceitos** se os comentários não forem respondidos e/ou resolvidos. Esteja de mente aberta e sempre disposto a crescer tanto como profissional quanto para crescermos como um time.OBS II: Comentários **NÃO SÃO IMPOSIÇÕES NEM LEIS**. Eles são sugestões. Se você discordar de alguma coisa, argumente, explique seu ponto de vista. Alguns “erros” podem ser apenas formas diferentes de fazer algo, que podem ser melhor vistas se você as explicar.OBS III: Não entendeu um comentário recebido? **PERGUNTE!** Responda o comentário com a sua dúvida ou entre em contato com o revisor.

Quando fazer Merge Requests

Nada lhe impede de fazer todo o desenvolvimento na branch de Dev e depois solicitar um merge request com todas as alterações que você fez no projeto inteiro. Evite fazer isso.

Quanto mais mudanças você submeter ao merge request, mais difícil será do revisor revisar o seu código, logo, também será mais demorado. Se você submeter um merge com o projeto inteiro de uma vez, imagine o quão difícil vai ser do revisor entender tudo o que você quis fazer.

Tendo isso em mente, seguem abaixo algumas etapas que são interessantes para se disparar um Merge Request:

• Para pequenas alterações em projetos já em execução: Sempre que uma alteração for feita. Ex: Um arquivo de configuração em um robô que roda todos os dias.

• Quando uma etapa do projeto for concluída: Se o seu RPA pode ser dividido em etapas, considere submetê-las para revisão assim que terminá-las. Quanto mais cedo uma falha for identificada, mais cedo ela poderá ser corrigida, e o impacto no projeto será menor.

• Quando quiser conferir se o projeto está ok com algum padrão: Se tiver estruturado seu projeto e quer saber se há algo de errado com ele, pode submetê-lo para obter um feedback do mesmo.

• No fim de cada dia: Essa é a frequência mínima para submissão. Se você trabalhou em um projeto no dia de hoje, submeta suas mudanças para serem revisadas. Assim, no dia seguinte, o revisor poderá ter revisado todas, senão, grande parte do seu progresso, e você poderá endereçar as mudanças que foram solicitadas.

• Quando achar necessário: Por fim, use seu julgamento. Quer uma revisão? Solicite uma. O revisor ficará feliz de ajudar.

Passo a Passo

Essa seção irá documentar todo o passo a passo para submeter mudanças para a branch de Release.

OBS: O passo a passo para submeter código para a branch de Dev ou qualquer outra branchNão Protegida permanece o mesmo.

1) Subindo código para uma branch Não Protegida

Se você tentar subir código diretamente para uma branch protegida, irá receber um erro como o que segue abaixo:

Mesmo estando autenticado, você recebeu um erro de falha de autenticação. Isso se dá pois você não tem autorização para fazer um commit diretamente para uma branch Protegida (ninguém tem).

Se receber um erro como esse, certifique-se que você está fazendo um commit para uma branch Não Protegida (no exemplo abaixo, dev):

2) Iniciando um merge request

Para iniciar um merge request, vá até a branch Não Protegida que você subiu o seu código e clique em Create merge request.

Você será redirecionado para uma página de Merge Request. Verifique se as branches de origem e destino estão corretas. Por exemplo, se você subiu o código para a branch Dev e quer que esse código seja incorporado na branch Release, então Dev é a branch de origem e Release é a branch de destino.

Caso os nomes não estejam batendo com o que você deseja, clique em Change Branches.

Ao alterar as branches, selecione as branches apropriadas de acordo com o seu Merge e clique em Compare branches and continue.

Você será redirecionado para a página anterior de criação de merge request. Escreva uma pequena descrição do seu merge (pontos chaves implementados que devem ter atenção do revisor) e selecione o usuário Maintainer que vai revisar seu código (geralmente esse usuário será Adriel Almeida dos Santos).

OBS: Certifique-se que a opção Squash commits when merge is accepted esteja DESMARCADA. Ativar essa opção poderá complicar o processo de merge.

Você irá se deparar com uma tela como essa. Agora basta esperar que o review seja feito.

3) Recebendo uma revisão

Você será notificado por email assim que o review for feito. Se necessário, poderá ter que alterar certas partes do código de acordo com o que foi solicitado pelos comentários do revisor.

Sempre que você receber um comentário, você poderá interagir com ele. Uma interação pode ser:

• Fazendo o que o comentário solicitou (responda “Feito”)
• Solicitando mais informações
• Discordando do ponto do comentário e explicando o seu ponto de vista
• Outros casos mais específicos

Dependendo do tipo de resposta do comentário você poderá:

• COMENTAR: Responde o comentário e solicita uma ação do revisor.
• COMENTAR E RESOLVER THREAD: Responde o comentário e marca aquela ação como resolvida/feita.

Para fazer uma ação acima, basta preencher o campo de comentário e clicar no botão correspondente a ela.

Quando um comentário solicita que ações sejam feitas no código, você poderá realizar novos commits dentro da mesma branch (Dev no exemplo) e isso já fará que o merge request seja atualizado.

Uma vez que uma thread seja resolvida, os comentários permanecerão no histórico. Se necessário, você (ou o revisor) poderá “DesResolver” a thread para voltar àquela discussão.

Alguns comentários do revisor podem conter sugestões, que são modificações propostas para o código já preparadas para serem adicionadas. Se você quiser incorporá-las, basta clicar no botão Apply Suggestion.

Uma vez que todos os comentários forem resolvidos, o revisor irá aprovar o Merge Request e as mudanças serão incorporadas.

O processo pode parecer longo e complexo, mas na verdade é bem intuitivo e direto ao ponto. Vale lembrar que todo esse processo é novo para todos, então alguns erros e imprevistos podem acontecer, então vamos trabalhar juntos para melhorar o processo ao máximo.