Como facilitar o review da sua tarefa
Tags: review, squad, documentation, organized
Published: 2021-02-28 20:52:15

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 Testes](https://i.imgur.com/YXfIfzu.png)



### 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.

![Roteiro de Deploy](https://i.imgur.com/6CtKXWV.png)  


## _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.

![Checklist de Informações](https://i.imgur.com/Ga83URR.png) 


### 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](https://github.com/), [GitLab](https://gitlab.com/) e [Bitbucket](https://bitbucket.org/), aceitão a linguagem [markdown](https://www.markdownguide.org/getting-started/), 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.

![Overview](https://i.imgur.com/l8tG7Yo.png?1)

### 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.