Revisão de Código em Projetos Android

O processo de Revisão de Código 🔍 pode ser cansativo, mas acredito que precisamos encarar esse processo como uma ótima oportunidade para aprender e compartilhar conhecimento 😍.

Preparei aqui uma lista de pontos que acredito serem fundamentais avaliar em revisões de código no cenário de desenvolvimento Android 🤖.

Vazamentos de memória 💥

Imagina o seguinte cenário: um aplicativo lindo e lento, aonde navegação entre telas deixa o aplicativo cada vez mais travado 😢

Pontos a serem verificados durante a revisão:

• Existe alguma retenção de Context nesse novo código?
• Se tem código RXAndroid, verificar se o dispose tá sendo realizado ao término do ciclo de vida do escopo (ViewModel/Fragment/Activity).
• Se for coroutines, o Job está atrelado ao escopo do ViewModel pra poder ser liberado corretamente?
• Se for uma implementação que usa CountDownTimer, AsyncTask, algum player de vídeo ou aúdio, provalvemente deve existir um cancel ou um release para liberação do recurso de memória alocado.
• Se for uma Fragment com ViewBinding, também precisa liberar o binding no onDestroyView.

Código retirado de https://developer.android.com/topic/libraries/view-binding

Layouts profundos 🌊🤿

As vezes pra fazer uma tela bacana precisamos de vários ViewGroups pra conseguir chegar a um efeito mais parecido com o protótipo, não é? 😛

Se for possível temos que evitar o aninhamento de ViewGroups (LinearLayouts, RelativeLayouts, FrameLayouts, …), pois as vezes o overdraw pode impactar a performance do aplicativo.

Dicas para reduzir o overdraw aqui.

Anotações de Recursos

Cada recurso no mundo Android tem um identificador, o qual é do tipo Inteiro. O problema é que as vezes esse Inteiro pode ser qualquer número e pode não ser um identificador válido de recurso. Por exemplo:

No código acima, o revisor poderia sugerir: “O que tu acha de colocarmos anotações de recursos? Algo assim:” (mostrar exemplo)

Outros exemplos legais de anotações aqui.

Componentes similares ✍️

É importante colocar esforço nas revisões de código, tentar pensar como o autor, refletindo suas escolhas. Não tem mal nenhum em fazer perguntas ❕❓

Código novo chegando, ops 🤔 “Esse código aqui faz algo parecido com o código dali”. Comentários como esse são fundamentais, porque quanto menos código escrevermos, menos 🐛 teremos, menos precisaremos testar e assim por diante. Cuidado com os componentes:

• Componente X pinta a lua de vermelho 🔴;
• Componente Z pinta a lua cheia de azul 🔵;
• Componente A pinta a lua de verde 🍏.

Por que não um componente capaz de pintar qualquer tipo de lua, o qual recebe a cor por parâmetro? Vale a pena? 🤔

Zonas de Perigo — Código altamente bugável ☠️

Existem códigos que só de pensarmos em arrumar ou adicionar uma funcionalidade dá um frio na barriga, não é? Então, estou falando daqueles códigos que o revisor comenta “Não consigo entender isso, não faz sentido 😢 Tu tem certeza disso?”.

Nesse cenário, não julgue o autor, chama ele para uma conversa e procura entender quais motivos ele teve pra ter feito essa escolha. Aqui pode estar uma oportunidade única para aprender 😜

Violação de Arquitetura 📐

A arquitetura nada mais é que um protocolo estabelecido de comunicação de pequenas partes de software.

A Revisão de Código é uma arma extremamente eficiente para identificar problemas como esse. Comentários são essenciais, por exemplo:

• “Colega o seu ViewModel está acessando os repositórios diretamente, a gente costuma criar UseCases para isso, dá uma olhada no arquivo MainViewModel. Temos um exemplo bem legal lá”
• “Porque você precisa de uma referência do Adapter aqui no ViewModel? O Adapter é da RecyclerView, acredito que faria sentido ficar na Fragment e bem distante do ViewModel”
• …

Pequenas coisas, mas que fazem a diferença… 🔍

• Imports não utilizados;
• Recursos como drawables, strings, colors não sendo utilizados;
• Código comentado;
• Código não formatado;
• Nome de variáveis, métodos e arquivos;
• Código que não segue nenhuma style guide. Por exemplo, o Kotlin possui uma style guide bem definida. Isso facilita muito um outro desenvolvedor compreender um código existente, por exemplo. Convenção do Kotlin: https://kotlinlang.org/docs/coding-conventions.html

Conclusão

Usar ferramentas de análise estática de código ajudam muito o processo de Revisão de Código, mas não descartam o olhar crítico de outro desenvolvedor. O código é patrimônio comum de um time de desenvolvimento, por isso cada um deve fazer a sua parte 🤗