4. Mas o que é código ruim?
• Seu amigo perguntou “o que é isso” mais de uma vez?
• Você foi tomar café e demorou pra voltar a pegar no tranco?
• Você utiliza mais ctrl + F do que ctrl + click?
5. O que a engenharia de software diz?
• Baixa coesão
• Alto acoplamento
• Code Smells
• Código duplicado
• Classes grandes
• Inveja de responsabilidade
6. Seu código precisa ser simples.
• Keep It Stupid Simple [KISS]
• Todos com o mínimo de conhecimento devem entender
• Você não escreve para você.
7. Se preocupe com seu código
• Pense que você é um professor:
• Faça que seus alunos aprendam direito
• E quando pegar alunos de outros professores, melhore-o.
• “Honestidade em pequenas coisas não é coisa pequena”
9. Sim, os nomes importam
• Nomes devem ser significativos
• Já parou pra pensar que você lê seu código em voz alta?
• Preste atenção na história que seu código conta
10. Métodos e Funções
• Faça uma coisa por vez
• Pense pequeno
• Evite contar mentiras no nome dos métodos
• Evite super classes
11. E os comentários
• Comentários tem tempo de validade, se for para usa-los zele por eles
assim como você zela pelo seu código.
• Um código simples pode falar mais que mil comentários
• Comentários podem facilmente virar mentiras, murmúrios, fofocas
12. Orientação à objetos
• Use e abuse
• Tenha sua própria toolbox de patterns
• Leia sobre, se interesse. A literatura sobre o tema é riquíssima!
14. Single Responsibility Principle
• Uma classe deve ter uma, e apenas uma, razão para mudar
• Uma classe deve ter apenas uma responsabilidade
• Uma classe deve ser coesa
15. Open Closed Principle
• Você deve ser capaz de estender o comportamento de uma classe
sem modifica-la
• Estender o comportamento de uma classe deve ser fácil
• Uma classe deve ser estável
16. Liskov Substitution Principle
• Classes derivadas devem ser trocáveis por sua classe pai
• Os filhos devem respeitar os contratos estabelecidos pelo pai
• Pré-condições podem ser afrouxadas e pós-condições apertadas
• Evite herança, favoreça composição
17. Interface Segregation Principle
• Faça interfaces magras específicas para clientes
• Aplique o Single Responsibility Principle em interfaces
• Deixe o filho escolher o que quer ser, não dê responsabilidades
demais á ele!
18. Dependecy Inversion Principle
• Dependa de abstrações
• Se preocupe apenas com o que é feito, não como é feito
• Injeção de dependência x Fábricas
19. Muita coisa? Veja melhor com eles!
Código limpo
(Robert C.
Martin)
Orientação a Objetos e
SOLID para Ninjas
(Maurício Aniche)