O documento discute princípios de código limpo e boas práticas de programação orientada a objetos, enfatizando a importância de escrever código simples, de fácil entendimento e manutenção. Apresenta conceitos como baixa acoplamento, alta coesão, princípios SOLID e a necessidade de seguir padrões como nomes significativos, métodos curtos e comentários atualizados. Também recomenda livros sobre o tema para aprendizado adicional.

1. Código Limpo
Porque fazer uma máquina entender é fácil ;)

2. Rômulo Massaroth de Farias
romulets
romulomfarias
romulodefarias@gmail.com

3. Quem lê nosso
código?

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”

8. Principio do escoteiro

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!

13. S O L I D

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)

20. Muito obrigado!
romulets
romulomfarias
romulodefarias@gmail.com