Apresentação WTM

497 visualizações

Publicada em

Palestra sobre SOLID e boa prática.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
497
No SlideShare
0
A partir de incorporações
0
Número de incorporações
13
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Apresentação WTM

  1. 1. De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo
  2. 2. Analista de Desenvolvimento no SERPRO & ex-Analista de Infra & @rubyonrio & @hackinrio & WTM & curiosa & hiperativa & tentando dominar o mundo Quem sou eu?
  3. 3. O que vamos ver? • SOLID (Boas práticas) • Código Limpo
  4. 4. O que vamos ver? • SOLID (Boas práticas) • Código Limpo
  5. 5. Tá mas porque isso é importante? ● Mais fácil para compreender ● Mais fácil de encontrar e resolver bugs Ou seja, melhora (e muito) a MANTENABILIDADE do código
  6. 6. O que contribui para um código feio? Eu quero é terminar rápido!!! Pra que fazer direito? Tô de saco cheio desse projeto já! Tenho que começar a fazer agora!!! Depois refatoro! Todo mundo faz assim!!!
  7. 7. O que contribui para um código feio? Eu quero é terminar rápido!!! Pra que fazer direito? Tô de saco cheio desse projeto já! Tenho que começar a fazer agora!!! Depois refatoro! Todo mundo faz assim!!!
  8. 8. Porque o código continua feio? ● Desenvolvedores saem do projeto ● Novos desenvolvedores entram no projeto e tem medo de modificar algo ● Mito de que demora muito mais tempo
  9. 9. O poder de mudar isso é nosso!
  10. 10. Respire fundo e....
  11. 11. E os comentários???? Não use!
  12. 12. Palma palma palma! Não priemos cânico!!!
  13. 13. O código deve ser o máximo possível auto-explicativo Comentários podem e devem ser usados, mas principalmente nas seguintes condições: ● Se não dá pra fazer nada melhor. ● Para alertar sobre algo importante sobre aquele trecho de código. ● TODO / FIXME
  14. 14. Ou seja...
  15. 15. Ou seja...
  16. 16. S O L I D ingle Responsibility pen-Closed iskov Substitution nterface Segregation ependency Inversion
  17. 17. Single Responsibility Cada classe ou método deve ter apenas uma responsabilidade, ou seja, mudar por apenas um motivo
  18. 18. Single Responsibility Cada classe ou método deve ter apenas uma responsabilidade, ou seja, mudar por apenas um motivo Objetivo: ● Classes ou métodos pequenas e coesas e fracamente acopladas
  19. 19. Open-Closed As classes devem ser abertas para extensão, mas fechadas para modificação.
  20. 20. Open-Closed As classes devem ser abertas para extensão, mas fechadas para modificação. Objetivos: ● Evolução do código mais fácil e rápida ● Melhorar a testabilidade
  21. 21. Open-Closed
  22. 22. Liskov Substitution Uma classe pode ser substituída por uma classe derivada dela sem a alteração de funcionamento de um método.
  23. 23. Liskov Substitution Uma classe pode ser substituída por uma classe derivada dela sem a alteração de funcionamento de um método. Objetivos: ● Reaproveitamento de código mais eficiente ● Melhorar a testabilidade
  24. 24. Liskov Substitution
  25. 25. Interface Segregation O cliente de uma classe não deve ser obrigado a herdar métodos que ele não utiliza.
  26. 26. Interface Segregation O cliente de uma classe não deve ser obrigado a herdar métodos que ele não utiliza. Objetivo: ● Interfaces menores, mais coesas e mais estáveis
  27. 27. Interface Segregation
  28. 28. Dependency Inversion Módulos de alto nível não devem depender de módulos de baixo nível e sim de abstrações e estas não devem depender de detalhes e sim os detalhes dependerem delas.
  29. 29. Dependency Inversion Módulos de alto nível não devem depender de módulos de baixo nível e sim de abstrações e estas não devem depender de detalhes e sim os detalhes dependerem delas. Objetivos: ● Diminuir o acoplamento entre os diferentes módulos ● Aumentar o reuso de classes
  30. 30. Dependency Inversion
  31. 31. Vamos lembrar sempre Isso são apenas boas práticas, não resolvem todos os problemas...
  32. 32. anna.cruz@gmail.com @yuizinha

×