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.
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
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?
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?
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 ''||''?
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?
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.
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.
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.
29.
30.
31.
32. CODEBASEMerge Requests /
Pull Requests
Autor
Conversa direta com o
desenvolvedor
WIKI e
Checklist
MR em avaliação
👎 ou 👍
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