Olá, sou Felipe Baraldi Dezidério e trabalho como desenvolvedor back end na Convenia. Aqui nós adotamos uma prática que dita: para entregar uma tarefa é necessário que seja validada e aprovada por ao menos 2 reviewers (revisores), sendo obrigatoriamente 1 deles do mesmo squad de quem desenvolveu a tarefa e o outro podendo ser de outro squad.

Para nós, fazer review não é apenas analisar o código e sim validar a tarefa toda. Ao realizar um review, é necessário você ter um contexto geral do que foi feito, qual o intuito da tarefa e qual o resultado esperado, senão o review pode se tornar apenas uma análise de código. Mas não vamos entrar em detalhes de como fazer um excelente review neste artigo, isso é assunto para outro artigo. Vamos tratar de como devemos entregar uma tarefa para que seja feito um bom review e diminuir os riscos de algum erro ou falha passarem.

Cuidados no desenvolvimento

Durante todo o desenvolvimento da tarefa devemos ir montando uma lista de tudo que é importante ser verificado por quem for fazer o review, quais os processos necessários para executar a tarefa em seu ambiente de desenvolvimento e também uma lista de tudo que é necessário para fazer o deploy da tarefa.

Vale ressaltar aqui que é muito importante fazer as anotações em conjunto com o desenvolvimento, se deixar para montá-las após o término do desenvolvimento, há uma enorme possibilidade de esquecermos de colocar algo importante e você pode ter certeza que isso vai acontecer em algum momento.

Roteiro de Testes

O roteiro de testes é a lista que você irá fazer para quem for revisar, é importante descrever nela todos os procedimentos necessários para executar o projeto em seu ambiente local e também os procedimentos que o reviewer (revisor) deve executar para verificar se as regras de negócio estão se comportando como é esperado.

Imagine que temos um sistema para RH (recursos humanos), onde gerenciamos tudo a respeito dos colaboradores de uma empresa e agora estamos desenvolvendo uma tarefa responsável por calcular o saldo de férias que um colaborador possui, para isso temos uma tabela em que diz, que quando o colaborador tem de 6 a 14 faltas ele perde o direito a 6 dias de férias e que quando tem de 15 á 23 dias de faltas ele perde o direito a 12 dias de férias.

Ao programar tais condicionais em meu sistema é importante eu já anotar essas regras em um roteiro de testes, para quem for fazer o review ter esse tipo de informação em mãos a modo de validar se tudo está ocorrendo dentre o esperado.

Roteiro de Deploy

O roteiro de deploy é a lista que você vai fazer para ser seguida durante o deploy da tarefa, essa lista por vezes pode estar em branco, quando nenhum procedimento novo for adicionado, mas seria um problemão se durante o deploy esquecermos de realizar algumas configurações necessárias em nosso servidor.

Imagine que ao desenvolver uma tarefa adicionamos o disparo de email para notificar um colaborador que suas férias estão próximas do vencimento, para isso precisamos adicionar uma conexão com servidor de email em nossas variáveis de ambiente, isso é algo que devemos anotar em nosso roteiro de deploy, pois quando nós fizermos o deploy da tarefa não podemos esquecer de configurar o servidor de email no ambiente de produção.

Checklist de Informações

Além dos roteiros de testes e deploy, temos uma checklist de informações relevantes que compartilhamos em todas as tarefas.
Essa checklist aborda verificações padrão para todas as aplicações.
São checados por exemplo se foi adicionado ou atualizado alguma dependência, se a documentação foi alterada, se a tarefa causa impacto em nosso ambiente de desenvolvimento, se a tarefa exige novas variáveis de ambiente, entre outros.
A checklist é sempre desenvolvida pelo autor da tarefa, nós a adotamos como um padrão pois durante o desenvolvimento de uma tarefa, é comum que alguns passos sejam esquecidos de seguir, além disso com o seu preenchimento, outros times também podem fazer a revisão da tarefa e por conta das situações pontuadas, podemos saber facilmente o que a tarefa engloba.

Montando o Overview

Agora que temos toda nossa tarefa desenvolvida, coberta por testes automatizados e com nossos roteiros escritos, então criamos nosso merge request para a branch de partida, ao criar o MR devemos escrever aqui um bom overview para nossos reviewers (revisores).

Geralmente o overview das plataformas de hopedagem de código-fonte e arquivos de controle de versão usando GIT, como as fomosas: GitHub, GitLab e Bitbucket, aceitam a linguagem markdown, então devemos abusar de todo o poder que temos em mãos, podemos usar título para separar os tópicos, negrito para destacar coisas importantes, listas para checklists, imagens para ilustrar a contextualização, tabela para expor alguma regra condicional e o que for necessário para deixar tudo mais bonito, harmonioso e de fácil entendimento.

Sugiro você começar colocando todos os links externos referentes a sua tarefa, como o do local onde está cadastrado a tarefa, do resultado do pipeline de verificação caso tenha um, da documentação caso exista, de outra MR relacionada a essa se houver e tudo que possa contribuir com quem for revisar.

Descrevendo a Tarefa

Após a sessão de links devemos colocar uma sessão para descrever sobre a tarefa, é nela que você deve contar qual o objetivo da tarefa, também você vai descrever tudo que foi realizado no desenvolvimento e as regras de negócio que foram seguidas. É muito importante ser bem detalhista em sua descrição leve-a sério, como se estivesse descrevendo a cena de uma crime para um juiz.

Quando um desenvolvedor de outro squad pegar para revisar uma tarefa que aborda sobre cálculo de folha pagamento, vão existir muitas regras que devem ser seguidas para cumprir com as legislações e o reviewer que não está por dentro do assunto precisa entender do que se trata, se não, não tem como ele garantir que a tarefa realizada está funcionando como realmente deveria.

Após a sessão de descrição da tarefa vocês podem colocar 1 para o roteiro de testes, 1 para o roteiro de deploy e 1 para a sua checklist padrão.

Conclusão

Se nós formos bem atenciosos com todos os detalhes durante o desenvolvimento e dermos o nosso melhor para anotar tudo o que for possível, não vamos correr risco de esquecer algo importante para trás. Tendo um overview bem detalhado com todas informações necessárias para quem for revisar, te dará a possibilidade de ter outros desenvolvedores que estão fora do seu squad revisando suas tarefas com segurança.

Por conta das mudanças, é possível que aos poucos, o processo de review entre times, se torne algo cada vez mais recorrente, pois nesta situação, é comum um time não ter tanto conhecimento da regra de negócio essencial de cada tarefa de outro squad.

Documentar o que for possível e deixar o acesso público para os desenvolvedores, pode aumentar as chances de uma revisão ser bem sucedida. Agora que temos tudo muito bem explicado, isso vai desafogar o squad já que dá uma possibilidade de outros desenvolvedores também revisarem e com tanta informação vai ser mais difícil deixar passar algum problema.

Artigo original publicado no site dev.to e republicado no iMasters a pedido do autor.