Concrete Logo
Hamburger button

O que devo procurar em um code review?

  • Blog
  • 5 de Janeiro de 2018
Share

Gostaria de dividir um pouco da minha experiência no time de operações da Concrete, no qual trabalho especificamente fazendo code reviews de um projeto Android.

Um livro que me ajudou bastante a fazer revisões de código foi o “What to Look for in a Code Review”, da Trisha Gee.

A autora faz muitas perguntas interessantes que devem ser feitas quando for fazer uma revisão de código.

Projeto

O novo código…

se adequa a arquitetura existente?

segue SOLID, DDD ou outros paradigmas de projeto que o time adota?

utiliza padrões de projetos adequados?

está no lugar certo?

reutiliza algo já existente no projeto ou introduz duplicação de código?

adiciona complexidade desnecessária?

Em nível de projeto devemos verificar se o merge request respeita o projeto como um todo, respeita os padrões adotados, não duplica código entre outras boas práticas.

Legibilidade e Manutenibilidade

Os nomes (campos, variáveis, parâmetros, métodos e classes) refletem no que eles representam?

É possível entender o que o código faz apenas lendo ele?

É possível entender o que o teste faz?

Os testes cobrem uma boa parte das classes? Eles cobrem o caminho feliz e os casos excepcionais? Existem classes que não foram cobertas?

Esse ponto é um dos mais importantes ao meu ver: o código deve ser o mais legível possível. Se o código novo contém vários comentários para explicar variáveis e métodos, muito provavelmente aquele código contém nomes ruins. Eu sempre encorajo outros desenvolvedores a remover comentários de métodos e renomeá-los, para que o nome explique exatamente o que está fazendo.

Leia Clean Code, do Robert Martin. Lá tem um capítulo especial para nomes. É excelente! Foi um divisor de águas na minha carreira como desenvolvedor. Aprendi bastante como deixar meu código mais claro, pensando na manutenibilidade do projeto e na legibilidade do código em si, pensando nos outros desenvolvedores.

Funcionalidade

O código realmente faz o que ele deveria fazer? Existem testes automatizados para garantir se o código está correto? Os testes realmente testam o código de acordo com os requisitos?

O código contém algum bug, como quando, acidentalmente, trocamos um “&&” por “||”?

O desenvolvedor pode estar respeitando os pontos citados anteriormente, mas pode ter deixado escapar uma lógica ou regra de negócio. Desenvolver testes automatizados ajudam bastante para não deixar esse problema passar.

Testes

Pergunte para si mesmo:

Existem testes para esse novo código?

Os testes cobrem, pelo menos, as partes confusas ou complicadas do código?

Eu consigo entender os testes?

Os testes verificam os requisitos?

Eu consigo pensar em partes não cobertas do código que deveriam ser testadas?

Existem testes para aspectos de segurança?

Existem testes de performance?

Por favor, testes seus códigos! Testar o seu software só vai lhe trazer vantagens. Você consegue, por exemplo, ter certeza caso alguma alteração impactou o projeto como um todo. O interessante é que o teste serve como documentação do seu software, por conter validação de regras de negócio, comportamentos esperados etc.

Dica: um padrão interessante a se utilizar nos testes é o Robot Pattern, apresentado pelo Jake Wharton. Que basicamente diz para separar “o que” seu teste valida, do “como” é feito para validar.

Vejamos um cenário de mudança de layout, por exemplo. A sua regra de negócio não vai mudar, mas os componentes visuais provavelmente vão. Adotando o Robot Pattern, você só vai precisar mudar a maneira de “como” testar.

Boas práticas de programação

SOLID;

DRY, Don’t repeat yourself: diz que quando se escreve a mesma coisa mais de uma vez é um erro;

Padrões de projeto: Ex Gang of Four;

Guidelines: Guideline oficial do Android (em Java) e a nova guideline Android Kotlin.

Provavelmente o seu projeto adota alguns padrões de projeto, a fim de manter o nexo entre as classes, fazer com que as features sigam para o mesmo caminho. Senão, o projeto vai virar um Frankenstein: cada feature desenvolvida de uma maneira, minimizando a reusabilidade de suas classes, aumentando a curva de aprendizado e vários outros pontos negativos.

SOLID é o acrônimo de cinco padrões de projeto que focam em produzir softwares mais entendíveis, flexíveis e manuteníveis. No Android, adotamos a guideline de desenvolvimento Java e Kotlin.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” (1999, Refactoring , Martin Fowler)

Code Review

Wiki

Tenha um documento que contenha todas as práticas adotadas em seu projeto. Utilizamos uma wiki como um documento vivo, que pode e deve ser alterado constantemente, acompanhando a evolução do projeto. É um ponto de referência e deve sempre estar sempre disponível aos desenvolvedores e revisores.

Checklist

Categorizamos vários pontos-chave da wiki, separamos os mais críticos e essenciais para a criação de um merge request, assim criamos um checklist. A fim de facilitar a tanto a vida do desenvolvedor na hora de criar um pull request quanto a vida do revisor ao verificar o que foi submetido. Se o desenvolvedor fizer o código respeitando o que lhe foi pedido no checklist e recomendações da wiki, muito provavelmente o seu código será aceito.

Ferramentas

Utilizamos algumas ferrementas que ajudam o desenvolvedor a seguir alguns padrões em tempo de desenvolvimento mesmo e outras feramentas só vão validar quando esse código for submetido no git.

Android Lint

O Android Studio oferece uma ferramenta de verificação de código chamada de Lint para ajudar a identificar e corrigir problemas com a qualidade estrutural do código, sem executar o aplicativo, nem criar casos de teste. Gera um relatório .html, o qual mostra o erro, sua gravidade como uma explicação detalhada e como corrigir ele.

Checkstyle

É uma ferramenta de desenvolvimento para ajudar os programadores a escrever código Java que aderira a um padrão de codificação. Ele automatiza o processo de verificação do código para poupar nós humanos dessa tarefa chata (o mas importante!). Isso o torna ideal para projetos que pretendem impor um padrão de codificação.

Pontos a serem validados: magic number, nomenclatura(de métodos, variáveis, constantes), identificação e uso correto de chaves.

Findbugs

O Findbugs é um outro analisador estático, mas opera em Bytecode Java, ao invés de código fonte. Identifica códigos Java que são passíveis de bug. Categorias de bugs avaliadas: Bad Pratice, Malicious Code Vunerability, Multithreaded Correctness, Performance, Security e Dodgy Code.

SonarQube

É uma plataforma de código aberto para inspeção contínua de qualidade para realizar revisões automáticas com análise estática de código para detectar erros, “bad smells” de código, vulnerabilidade de segurança, entre outros. É compatível com mais de 20 linguagens de programação, entre elas, Java.

Dicas de livros

Gostaria de indicar alguns outros livros que me ajudaram bastante a entender melhor questões de boas práticas de desenvolvimento, conduta profissional, limpeza de código, entre outros.

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin Series) / Edition 1

Agile Principles, Patterns, and Practices in C#

The Pragmatic Programmer

Vídeo

Esse post é uma continuação da apresentação que fiz no GDG-SP e no Javaneiros.

Caso queira ver a minha apresentação no Android Meetup #53, confira o vídeo aqui.

Bibliografia

https://leanpub.com/whattolookforinacodereview
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
https://martinfowler.com/books/refactoring.html
https://www.slideshare.net/ChristianeMoraisSilv
http://wiki.c2.com/?GangOfFour
https://source.android.com/source/code-style
https://android.github.io/kotlin-guides/style.html
https://developer.android.com/studio/write/lint.html
http://checkstyle.sourceforge.net/index.html
https://docs.gradle.org/current/userguide/checkstyle_plugin.html
http://findbugs.sourceforge.net/
https://www.sonarqube.org/
https://www.slideshare.net/RodrigodeSouzaCastro/o-que-devo-procurar-em-um-code-review-81769974

É desenvolvedor Java e gostaria de trabalhar em um time ágil e multidisciplinar? Clique aqui!