Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

O que devo procurar em um code review

242 views

Published on

Dicas de pontos importantes para serem analizados em um code review.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

O que devo procurar em um code review

  1. 1. O QUE DEVO PROCURAR EM UM CODE REVIEW? http://bit.ly/procurar-code-review
  2. 2. 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
  3. 3. SUMÁRIO •Projeto •Legibilidade e Manutenibilidade •Funcionalidade •Testes •Boas práticas de programação •Code Review •Ferramentas
  4. 4. PROJETO
  5. 5. 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?
  6. 6. LEGIBILIDADE E MANUTENIBILIDADE
  7. 7. 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?
  8. 8. FUNCIONALIDADE
  9. 9. 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 ''||''?
  10. 10. TESTES
  11. 11. 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?
  12. 12. BOAS PRÁTICAS DE PROGRAMAÇÃO
  13. 13. 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.
  14. 14. 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.
  15. 15. BOAS PRÁTICAS DE PROGRAMAÇÃO SOLID DRY Padrões de Projeto Guidelines
  16. 16. BOAS PRÁTICAS DE PROGRAMAÇÃO SOLID DRY Padrões de Projeto Guidelines
  17. 17. "Any fool can write code that a computer can understand. Good programmers write code that humans can understand. MARTIN FOWLER, REFACTORING - 1999
  18. 18. CODE REVIEW
  19. 19. 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.
  20. 20. 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.
  21. 21. http://www.osnews.com/story/19266/WTFs_m
  22. 22. FERRAMENTAS
  23. 23. 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.
  24. 24. 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. CODEBASEMerge Requests / Pull Requests Autor Conversa direta com o desenvolvedor WIKI e Checklist MR em avaliação 👎 ou 👍
  28. 28. DICAS DE LIVROS
  29. 29. 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/
  30. 30. OBRIGADO!
  31. 31. 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

×