O documento discute o que deve ser procurado em uma revisão de código, incluindo se o código se adequa à arquitetura do projeto, é legível e mantível, contém testes adequados e segue boas práticas de programação. Ele também lista ferramentas como Lint, Checkstyle e SonarQube que podem auxiliar na análise do código.

2. O QUE DEVO
PROCURAR EM UM
CODE REVIEW?
http://bit.ly/procurar-code-review

3. RODRIGO CASTRO
Desenvolvedor Android @ Concrete
Analista de Sistemas pela UFMS/CPCX.
De Coxim/MS para o mundo!
http://castrors.github.io
rodrigo.castro@concrete.com.br
@rodrigocastro_o

4. SUMÁRIO
•Projeto
•Legibilidade e Manutenibilidade
•Funcionalidade
•Testes
•Boas práticas de programação
•Code Review
•Ferramentas

5. PROJETO

6. O novo código...
● se adequa a arquitetura existente?
● segue SOLID, DDD ou outro paradigma 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?

7. LEGIBILIDADE E
MANUTENIBILIDADE

8. LEGIBILIDADE E
MANUTENIBILIDADE
● Os nomes(campos, variáveis, parametros, 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? Ele cobre o caminho
feliz e os casos excepcionais? Existem classes que não foram
cobertas?

9. FUNCIONALIDADE

10. FUNCIONALIDADE
● O código realmente faz o que ele deveria fazer? Existem testes
automatizados para garantir se o código está correto, se os testes
realmente testam o código de acordo com os requisitos?
● O código contém algum bug, como acidentalmente trocar um ''&&''
por ''||''?

11. TESTES

12. Pergunte para si mesmo
essas perguntas:
● Existe testes para esse novo código?
● Os testes cobrem pelo menos as partes confusas ou complicadas do
código?
● Eu consigo entender os testes? (Robot Pattern - @jakewharton)
● 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?

13. BOAS PRÁTICAS DE
PROGRAMAÇÃO

14. BOAS PRÁTICAS DE
PROGRAMAÇÃO
SOLID
DRY
Padrões de Projeto
Guidelines
SRP - The single responsibility principle - A class should
have one, and only one, reason to change.
OCP - The Open Closed Principle - You should be able to
extend a classes behavior, without modifying it.
LSP - The Liskov Substitution Principle - Derived
classes must be substitutable for their base classes.
ISP - The Interface Segregation Principle - Make fine
grained interfaces that are client specific.
DIP- The Dependency Inversion Principle - Depend on
abstractions, not on concretions.

15. BOAS PRÁTICAS DE
PROGRAMAÇÃO
SOLID
DRY
Padrões de Projeto
Guidelines
DRY – “Don’t Repeat Yourself” – suggests that writing the
same code over and over again is a bad thing.

16. BOAS PRÁTICAS DE
PROGRAMAÇÃO
SOLID
DRY
Padrões de Projeto
Guidelines

17. BOAS PRÁTICAS DE
PROGRAMAÇÃO
SOLID
DRY
Padrões de Projeto
Guidelines

18. "Any fool can write code that a computer can understand. Good
programmers write code that humans can understand.
MARTIN FOWLER, REFACTORING - 1999

19. CODE REVIEW

20. CODE REVIEW
WIKI
Checklist
Tenha um documento que contenha todas as práticas
adotadas no seu projeto.
É um documento vivo, que pode e deve ser alterado
constantemente, acompanhando a evolução do projeto.
Deve estar sempre disponível aos desenvolvedores e
revisores.
Wiki? Livro? Etc.

21. CODE REVIEW
WIKI
Checklist Categorize cada ponto que foram citados anteriormente,
e separe em uma checklist. Desta maneira facilitará tanto
a vida do desenvolvedor na hora de criar um pull request
quanto a vida do revisor ao verificar o que foi submetido.

23. http://www.osnews.com/story/19266/WTFs_m

24. FERRAMENTAS

25. FERRAMENTAS
Android Lint
Checkstyle
Findbugs
SonarQube
O Android Studio oferece uma ferramenta de verificação
de código denominada 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, gravidade,
explicação detalhada e como corrigir.

26. FERRAMENTAS
Android Lint
Checkstyle
Findbugs
SonarQube
Checkstyle é uma ferramenta de desenvolvimento para
ajudar os programadores a escrever código Java que adira
a um padrão de codificação. Ele automatiza o processo de
verificação do código Java para poupar humanos dessa
tarefa chata (mas importante). Isso o torna ideal para
projetos que desejam impor um padrão de codificação.
Pontos a serem validados: Magic Number, Nomenclatura
(de métodos, variáveis, constantes), Identação, uso correto
de chaves.

27. FERRAMENTAS
Android Lint
Checkstyle
Findbugs
SonarQube
FindBugs é um analisador de código estático de código
aberto criado por Bill Pugh e David Hovemeyer, que
detecta possíveis erros em programas Java. Os erros
potenciais são classificados em quatro categorias: (i) mais
assustador, (ii) assustador, (iii) preocupante e (iv) de
preocupação. Esta é uma pista para o desenvolvedor
sobre o seu possível impacto ou gravidade. FindBugs
opera em bytecode Java, em vez de código fonte.
Categorias de bugs avaliadas: Bad Practice, Malicious code
vunerability, Multitheaded correctness, Performance,
Security, Dodgy code.

28. FERRAMENTAS
Android Lint
Checkstyle
Findbugs
SonarQube
O SonarSource oferece o que provavelmente é o melhor
analisador de código estático que você pode encontrar no
mercado para Java. Com base no nosso próprio front-end
do compilador Java, ele usa as técnicas mais avançadas
(correspondência de padrões, análise de fluxo de dados)
para analisar código e encontrar cheiros de código, bugs
e vulnerabilidades de segurança. Quanto a qualquer
produto que desenvolvamos no SonarSource, foi
construído com os seguintes princípios: profundidade,
precisão e velocidade.

32. CODEBASEMerge Requests /
Pull Requests
Autor
Conversa direta com o
desenvolvedor
WIKI e
Checklist
MR em avaliação
👎 ou 👍

33. DICAS DE LIVROS

34. 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/

35. OBRIGADO!

36. Centro
Av. Presidente Wilson,
231 - 29º andar
(21) 2240-2030
Cidade Monções
Av. Nações Unidas,
11.541 - 3º andar
(11) 4119-0449
Savassi
Av. Getúlio Vargas, 671
Sala 800 - 8º andar
(31) 3360-8900
www.concrete.com.b
r