SlideShare une entreprise Scribd logo
1  sur  10
Télécharger pour lire hors ligne
Code Review 
Rafael Oliveira 
<rafaelo@take.net>
Antes de revisar... 
•Check in early, check in often! 
–Segurança 
•Se o código não está no repositório, não existe! 
–O objetivo não é subir código quebrado 
•Incompleto != Quebrado 
–Check in com frequência, permite um feedback mais rápido 
•A revisão do código é menos trabalhosa 
2
•DRY 
“Every piece of 
knowledge must have a single, unambiguous, authoritative representation within a system.” 
•KISS 
"Simplicity is the ultimate sophistication" 
•YAGNI 
“Build what you need as you need it.” 
3
•Sem comentários pertinentes 
•‘Comentar’ o teste em busca do ‘green’ 
–Assert.IsTrue(true); 
•Sem tratamento de erros 
4
•Código mal formatado 
•Linhas extensas 
•Métodos enormes 
•Erros de digitação 
5
•Reduzir erros 
•Garantir os padrões 
•Aprender 
•Ensinar 
•Melhorar a capacidade de manutenção, segurança, documentação, qualidade... 
Por que revisar? 
6
Então, o que revisar? 
•Funcionalidades 
–Está dentro do esperado pela atividade? 
–A lógica está correta? 
•Design 
–Baixo acoplamento e alta coesão? 
–A classe está muito grande ou muito complexa? 
7
Então, o que revisar? 
•Estilo de código 
–Atende aos padrões definidos pela empresa? 
–Tem código duplicado? 
•Nomenclatura 
–Nomes coerentes e consistentes? 
–Erros de digitação, idioma? 
8
Então, o que revisar? 
•Tratamento de erros 
–Como os erros estão sendo tratados? 
–O código está tratando todos os erros que podem acontecer? 
•Segurança 
–Há algum princípio sendo violado? 
•Testes de unidade 
–Foram escritos? Bem escritos? São coerentes? 
9
17

Contenu connexe

Similaire à Code review

WebCamps Software Testing
WebCamps Software TestingWebCamps Software Testing
WebCamps Software Testing
Rodrigo Vidal
 
TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
Icaro Camelo
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Neubio Ferreira
 
Aprensentacao oo-trincheiras
Aprensentacao oo-trincheirasAprensentacao oo-trincheiras
Aprensentacao oo-trincheiras
Higor César
 
Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
Pedro Pereira Martins
 

Similaire à Code review (20)

DevSecOps - Segurança em um pipeline contínuo
DevSecOps - Segurança em um pipeline contínuoDevSecOps - Segurança em um pipeline contínuo
DevSecOps - Segurança em um pipeline contínuo
 
WebCamps Software Testing
WebCamps Software TestingWebCamps Software Testing
WebCamps Software Testing
 
TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação TDD: Técnicas, Benefícios e Limitação
TDD: Técnicas, Benefícios e Limitação
 
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MGModelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
Modelagem Ágil - UaiJug TechDays 2013 - Uberlândia MG
 
PHP Anti Patterns
PHP Anti PatternsPHP Anti Patterns
PHP Anti Patterns
 
IT Talks - 7 principais desperdícios em desenvolvimento de software
IT Talks - 7 principais desperdícios em desenvolvimento de softwareIT Talks - 7 principais desperdícios em desenvolvimento de software
IT Talks - 7 principais desperdícios em desenvolvimento de software
 
Clean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimentoClean Code - Boas práticas para desenvolvimento
Clean Code - Boas práticas para desenvolvimento
 
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
Desenvolvimento ágil com Scrum e TFS 11 - Microsoft TechDay Sorocaba 2012
 
Potencializando a qualidade de código
Potencializando a qualidade de códigoPotencializando a qualidade de código
Potencializando a qualidade de código
 
Não vão me invadir!
Não vão me invadir!Não vão me invadir!
Não vão me invadir!
 
Verdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostariaVerdades e mitos sobre testes que eu gostaria
Verdades e mitos sobre testes que eu gostaria
 
Introdução ao XP
Introdução ao XPIntrodução ao XP
Introdução ao XP
 
Introdução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de DesenvolvimentoIntrodução às Metodologias Ágeis de Desenvolvimento
Introdução às Metodologias Ágeis de Desenvolvimento
 
Desenvolvimento Orientado a Testes
Desenvolvimento Orientado a TestesDesenvolvimento Orientado a Testes
Desenvolvimento Orientado a Testes
 
Aprensentacao oo-trincheiras
Aprensentacao oo-trincheirasAprensentacao oo-trincheiras
Aprensentacao oo-trincheiras
 
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software LeanMinicurso: Uma Introdução ao Desenvolvimento de Software Lean
Minicurso: Uma Introdução ao Desenvolvimento de Software Lean
 
Introdução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCastingIntrodução ao TDD nas soluções Global AppCasting
Introdução ao TDD nas soluções Global AppCasting
 
Você quer ser um excelente programador  desenvolvedor mas não sabe como começar?
Você quer ser um excelente programador  desenvolvedor mas não sabe como começar?Você quer ser um excelente programador  desenvolvedor mas não sabe como começar?
Você quer ser um excelente programador  desenvolvedor mas não sabe como começar?
 
Roadsec Salvador 2014
Roadsec Salvador 2014Roadsec Salvador 2014
Roadsec Salvador 2014
 
Testes de Unidade, por que você deve começar a fazer? - Javaneiros
Testes de Unidade, por que você deve começar a fazer? - JavaneirosTestes de Unidade, por que você deve começar a fazer? - Javaneiros
Testes de Unidade, por que você deve começar a fazer? - Javaneiros
 

Dernier

Dernier (6)

ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docxATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
ATIVIDADE 1 - LOGÍSTICA EMPRESARIAL - 52_2024.docx
 
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docxATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
ATIVIDADE 1 - CUSTOS DE PRODUÇÃO - 52_2024.docx
 
ATIVIDADE 1 - ESTRUTURA DE DADOS II - 52_2024.docx
ATIVIDADE 1 - ESTRUTURA DE DADOS II - 52_2024.docxATIVIDADE 1 - ESTRUTURA DE DADOS II - 52_2024.docx
ATIVIDADE 1 - ESTRUTURA DE DADOS II - 52_2024.docx
 
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docxATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
ATIVIDADE 1 - GCOM - GESTÃO DA INFORMAÇÃO - 54_2024.docx
 
Boas práticas de programação com Object Calisthenics
Boas práticas de programação com Object CalisthenicsBoas práticas de programação com Object Calisthenics
Boas práticas de programação com Object Calisthenics
 
Padrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemploPadrões de Projeto: Proxy e Command com exemplo
Padrões de Projeto: Proxy e Command com exemplo
 

Code review

  • 1. Code Review Rafael Oliveira <rafaelo@take.net>
  • 2. Antes de revisar... •Check in early, check in often! –Segurança •Se o código não está no repositório, não existe! –O objetivo não é subir código quebrado •Incompleto != Quebrado –Check in com frequência, permite um feedback mais rápido •A revisão do código é menos trabalhosa 2
  • 3. •DRY “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” •KISS "Simplicity is the ultimate sophistication" •YAGNI “Build what you need as you need it.” 3
  • 4. •Sem comentários pertinentes •‘Comentar’ o teste em busca do ‘green’ –Assert.IsTrue(true); •Sem tratamento de erros 4
  • 5. •Código mal formatado •Linhas extensas •Métodos enormes •Erros de digitação 5
  • 6. •Reduzir erros •Garantir os padrões •Aprender •Ensinar •Melhorar a capacidade de manutenção, segurança, documentação, qualidade... Por que revisar? 6
  • 7. Então, o que revisar? •Funcionalidades –Está dentro do esperado pela atividade? –A lógica está correta? •Design –Baixo acoplamento e alta coesão? –A classe está muito grande ou muito complexa? 7
  • 8. Então, o que revisar? •Estilo de código –Atende aos padrões definidos pela empresa? –Tem código duplicado? •Nomenclatura –Nomes coerentes e consistentes? –Erros de digitação, idioma? 8
  • 9. Então, o que revisar? •Tratamento de erros –Como os erros estão sendo tratados? –O código está tratando todos os erros que podem acontecer? •Segurança –Há algum princípio sendo violado? •Testes de unidade –Foram escritos? Bem escritos? São coerentes? 9
  • 10. 17