Friendly code review

A boa e velha revisão de código, popular entre times ágeis e matéria-prima para aquelas piadas na hora do café. Seja você um desenvolvedor experiente ou iniciante, já deve ter tido algum contato com code review e aposto que já sentiu um frio na espinha ao ter o código revisado por outra pessoa. Esse sentimento é natural e muito comum, afinal, tem alguém procurando falhas na sua implementação. Porém, isso pode tornar o processo doloroso, tanto para o desenvolvedor, quanto para o revisor. Aceitar sugestões e aprender com elas ou sugerir melhorias realmente relevantes não é nada trivial. Mas afinal, este processo precisa mesmo gerar incômodo? Como podemos tornar o code review mais amigável sem deixar de ser pragmático?

Code Review Driven Development

Uma boa alternativa é pedir a opinião de outros desenvolvedores constantemente, antes mesmo do código estar pronto. Faça isso no dia a dia, disponibilize um branch ou shelveset (dependendo do controlador de versão que estiver usando) com o trecho do código para ser revisado, ou faça pair programming para obter um feedback imediato. O objetivo é transformar essa prática em um hábito transformando a revisão, antes tensa e burocrática, em uma conversa casual. Essa troca de experiências entre desenvolvedores só agrega valor para o projeto e para os envolvidos. Meio óbvio, eu sei, mas muitas empresas não veem revisão de código como parte essencial no processo de desenvolvimento.

Outra prática interessante: de tempos em tempos volte seus olhos para seu código antigo, de meses atrás, você terá as duas perspectivas, será revisor e desenvolvedor. Muito provavelmente o feedback será amigável, afinal é o seu trabalho que você está avaliando, e também será receptivo com as sugestões. Claro que não dá pra fazer isso sempre e pode parecer meio bobo, mas vale a tentativa.

Friendly and Pragmatic

Um code review amigável é algo que pode ser feito tanto pelo desenvolvedor quanto pelo revisor, é uma via de mão dupla. Como desenvolvedor você pode:

1. Pedir, constantemente, feedbacks para pequenos trechos de código. Assim o resultado final terá uma melhor qualidade e gerará menos retrabalho;
2. Revisar as regras do projeto utilizadas pelo time antes de abrir o pull request (ou merge request). Caso não haja nenhuma, construa isso com seu time;
3. Documentar corretamente o que precisa ser avaliado e como validar a implementação. Explique de maneira clara e concisa o objetivo do seu código;
4. Garantir o bom funcionamento do código, cobrindo-o com testes unitários (essa pode até ser uma regra para o seu time);
5. Evitar ao máximo revisões para trechos gigantes de código, com dezenas de arquivos alterados. Coloque-se no lugar do revisor, você gostaria de avaliar mais de 60 arquivos com alterações? Aposto que não.

Como revisor, você pode:

1. Ser um mentor. Ao revisar um código assuma a postura de mentor, o seu objetivo não é mais procurar por falhas na implementação, e sim mostrar como o desenvolvedor pode fazer melhor. Caso não possua experiência ou conhecimento necessário, peça ajuda para um desenvolvedor mais experiente, ou utilize ferramentas para análise de qualidade de código, como o sonarqube que possui plugins para as principais IDEs em mais de 20 linguagens de programação;
2. Não ser chato, evitar revisões do tipo: “Trocar o if (objeto == null) para if (Objects.isNull(objeto))!”. Se você olhar a implementação do isNull dentro da classe Objects verá que é a mesma coisa, procure agregar valor real em suas revisões;
3. Revisar rápido e analisar de verdade. Tenha em mente que o tempo dos dois é importante, não desperdice muito tempo revisando e também não faça o desenvolvedor ficar dias esperando seu feedback. Revisar não é apenas passar o olho ou executar os testes, analise de verdade o código. Depois de aprovado, aquele código passa a ser sua responsabilidade também;
4. Ter um check list. Tudo na vida funciona melhor quando se sabe o que fazer. Ele vai te ajudar com o que procurar e por onde seguir. Por exemplo:

Keep going up

Revisar o código constantemente ajuda a manter seus projetos, e seus conhecimentos, em constante desenvolvimento. Dessa forma, a qualidade do código é aprimorada e você evolui como profissional. É uma relação ganha-ganha.

Aqui na Aurum, nós temos plena ciência disso e procuramos sempre melhorar a qualidade das revisões e do processo. Possuímos algumas regras para revisão (o código deve possuir uma cobertura razoável de testes unitários) e tornamos a discussão sobre qualidade de software uma rotina do time.

Para finalizar, seguem alguns conteúdos que podem melhorar sua coding skill para mandar bem na hora do code review:

1. Livro: Clean Code by Robert C. Martin
2. Livro: Refactoring by Martin Fowler
3. Livro: Head Firts - Design Patters by Eric Freeman and Bert Bates
4. Livro: Orientação a Objetos e SOLID para Ninjas by
   Maurício Aniche
5. Podcast: BranasCast - Code Review by
   Rodrigo Branas
6. Blog post: Why code reviews matter by Dan Radigan

Que a força esteja com você!