O documento fornece diretrizes para revisão de código, enfatizando a importância de: 1) check-ins frequentes para feedback rápido; 2) seguindo princípios como DRY, KISS e YAGNI; 3) evitando comentários desnecessários e testes superficiais.
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
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