Qual é meu papel durante o code review?
Continuando a série de posts sobre code review, chegou a hora de falar sobre algo importante: os papéis. Para um review de qualidade é necessário entender qual seu papel nesse processo e como gerar valor no tempo investido.
Basicamente existem dois papéis: o autor e o revisor. Cada um deles implica em ter um postura diferente durante o processo, por meio do qual um deverá fornecer contexto e o outro deverá estimular o debate.
Abaixo vamos conhecer um pouco sobre cada um.
O autor
Esse papel se refere a quem implementou a funcionalidade, corrigiu o bug, etc. Embora pareça um papel onde basicamente só se deve enviar uma pull request e avisar aos colegas, existe algo muito importante que o autor deve fornecer: o contexto.
Embora façamos reuniões diárias, reuniões de planejamento, entre outras. É comum um colega não saber exatamente o que estamos fazendo. Por isso o autor deve fornecer o contexto no qual está trabalhando, para que assim, o revisor consiga entender de fato o que foi implementado.
Por isso o autor deve fornecer o contexto no qual está trabalhando, para que assim, o revisor possa entender de fato o que foi implementado.
Como o autor pode fornecer o contexto?
Uma forma bastante simples e direta de fazer isso é respondendo três perguntas:
- Por que essa mudança é necessária?
- Como o problema foi atacado?
- Quais os efeitos colaterais que essa implementação traz?
Na primeira pergunta o autor deve explicar o porquê dessa mudança, no caso de uma funcionalidade deve descrever o objetivo da mesma, por exemplo, “atualmente o usuário não pode alterar sua foto”, “quando o usuário clica em salvar acontece o bug X”, etc.
Na segunda pergunta o objetivo é um pouco mais técnico, porque a ideia dela é explicar de forma rasa qual a lógica utilizada para resolver o problema, por exemplo, “quando o usuário envia o formulário, caso os dados sejam válidos, o UserRepository salva os dados no banco”.
Por fim, na terceira pergunta o autor deve explicar o que muda no sistema com essa implementação, por exemplo, “agora quando o usuário edita seus dados é redirecionado para a página X”, “com isso os arquivos são salvos no S3 e não mais na própria máquina, permitindo escalabilidade”.
É dessa forma que os autores das pull requets fornecem um contexto para quem irá revisar o tarefa, antes de autorizar o merge aqui na Softfocus. No fim, o autor deve colocar um link para a tarefa original no fim do texto (ex: Trello, Jira, etc).
O revisor
Diferente do autor, o revisor deve avaliar o trabalho feito pelo seu colega. Quando digo avaliar, não me refiro a julgar, mas a instigar um debate sobre o trabalho final a fim de chegar um acordo entre as partes por meio da argumentação lógica.
Pergunte, não dê ordens
Ao invés de comentar o código do seu colega com “mude isso”, “faz isso assim” ou “está tudo errado refaça”, o revisor deve perguntar para instigar o debate. Pode-se usar perguntas como “não seria mais interessante trocar esses nomes para ganhar mais significado?”, “não acha que essa classe possui responsabilidades demais? E se seguíssemos a ideia do SRP?”. Essas perguntas vão forçar o autor a pensar sobre sua implementação para conseguir argumentar e defendê-la.
Uma vez tendo que pensar por conta própria, tendo recebido algumas possíveis falhas em seu raciocínio inicial, o autor chegará a suas próprias conclusões de como melhorar a implementação.
Por meio dessa técnica evitamos o conflito e guiamos os outros ao invés de dar ordens. A ideia dessa abordagem é evitar o conflito direto utilizando o método socrático.
Ajude com as correções e mudanças
Avaliar algo é fácil, porém, muitas vezes o colega pode levar um bom tempo para absorver a nova informação. Por isso é bom explicar pessoalmente o porquê de alguns comentários e também oferecer ajuda para resolver as pendências.
Uma boa técnica para isso é oferecer-se para fazer pair programming. Preferencialmente, deixando o colega programar e passando dicas na hora de refatorar o código ou refazer algo.
Conclusão
Uma boa forma de evoluir em diversos aspectos é questionar aquilo que temos como verdade. É assim que a ciência evolui e sem dúvidas é uma boa forma de nos aperfeiçoarmos como profissionais. Dessa forma devemos estar abertos aos questinamento, analisando cada sugestão de forma lógica e nunca levando nada para o lado pessoal.
Ter essa consciência em relação ao code review é fundamental para conseguirmos compartilhar conhecimento e estabelecer uma forte comunicação entre os membros da equipe. Comunicação essa, que é a base para qualquer equipe de sucesso.
Referências
Resolvi montar um repositório no Github para guardar links importantes sobre code review, portanto todas as minhas referências estão lá. Porém, para entender melhor esse post recomendo assistir a talk Implementing a Strong Code-Review Culture e ler o post There’s a human on the other side of your code review.
