De Freddy Krueger à Brad Pitt.
Como melhorar o seu código e fazê-lo ficar lindo
Analista de Desenvolvimento & ex-Infra
(fora do SERPRO) & @rubyonrio & curiosa
& hiperativa & tentando dominar o mundo
Que...
O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo
O que vamos ver?
• SOLID (Boas práticas)
• Código Limpo
Tá mas porque isso é
importante?
● Mais fácil para compreender
● Mais fácil de encontrar e resolver bugs
Ou seja, melhora ...
O que contribui para um código
feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse
projeto j...
O que contribui para um código
feio?
Eu quero é terminar rápido!!!
Pra que fazer direito? Tô de saco cheio desse
projeto j...
Porque o código continua feio?
● Desenvolvedores saem do projeto
● Novos desenvolvedores entram no projeto e
tem medo de m...
O poder de mudar isso é nosso!
Respire fundo e....
Sobre o uso de comentários:
Não use!
Sobre o uso de comentários:
Não use!
Calma calma calma! Não criemos
pânico!!!
O código deve ser o máximo possível
auto-explicativo
Comentários podem e devem ser
usados, mas principalmente nas
seguinte...
S
O
L
I
D
ingle Responsibility
pen-Closed
iskov Substitution
nterface Segregation
ependency Inversion
Single Responsibility
Cada classe ou método deve ter apenas uma
responsabilidade, ou seja, mudar por apenas
um motivo
Single Responsibility
Cada classe ou método deve ter apenas uma
responsabilidade, ou seja, mudar por apenas
um motivo
Obje...
Single Responsibility
Single Responsibility
Open-Closed
As classes devem ser abertas para extensão,
mas fechadas para modificação.
Open-Closed
As classes devem ser abertas para extensão,
mas fechadas para modificação.
Objetivos:
● Evolução do código mai...
Open-Closed
Open-Closed
Liskov Substitution
Uma classe pode ser substituída por uma
classe derivada dela sem a alteração de
funcionamento de um mé...
Liskov Substitution
Uma classe pode ser substituída por uma
classe derivada dela sem a alteração de
funcionamento de um mé...
Liskov Substitution
Liskov Substitution
Interface Segregation
O cliente de uma classe não deve ser
obrigado a herdar métodos que ele não
utiliza.
Interface Segregation
O cliente de uma classe não deve ser
obrigado a herdar métodos que ele não
utiliza.
Objetivo:
● Inte...
Interface Segregation
Interface Segregation
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 de...
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 de...
Dependency Inversion
Dependency Inversion
Anna Cruz
anna-graciela.cruz@serpro.gov.br
#7705
DE706
Códigos em
https://github.com/annacruz/exemplos-devday-serpro
De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo
De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo
De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo
Próximos SlideShares
Carregando em…5
×

De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo

131 visualizações

Publicada em

Palestra ocorrida no primerio dev day do SERPRO RJ sobre SOLID e boas práticas de programação.

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

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

Nenhuma nota no slide

De Fred Krueger a Brad Pitt como melhorar o seu código e fazê-lo ficar lindo

  1. 1. De Freddy Krueger à Brad Pitt. Como melhorar o seu código e fazê-lo ficar lindo
  2. 2. Analista de Desenvolvimento & ex-Infra (fora do SERPRO) & @rubyonrio & 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. Sobre o uso de comentários: Não use!
  12. 12. Sobre o uso de comentários: Não use! Calma calma calma! Não criemos pâ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. S O L I D ingle Responsibility pen-Closed iskov Substitution nterface Segregation ependency Inversion
  15. 15. Single Responsibility Cada classe ou método deve ter apenas uma responsabilidade, ou seja, mudar por apenas um motivo
  16. 16. 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
  17. 17. Single Responsibility
  18. 18. Single Responsibility
  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. Open-Closed
  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.
  24. 24. 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
  25. 25. Liskov Substitution
  26. 26. Liskov Substitution
  27. 27. Interface Segregation O cliente de uma classe não deve ser obrigado a herdar métodos que ele não utiliza.
  28. 28. 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
  29. 29. Interface Segregation
  30. 30. Interface Segregation
  31. 31. 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.
  32. 32. 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 a coesão entre os diferentes módulos ● Aumentar o reuso de classes
  33. 33. Dependency Inversion
  34. 34. Dependency Inversion
  35. 35. Anna Cruz anna-graciela.cruz@serpro.gov.br #7705 DE706 Códigos em https://github.com/annacruz/exemplos-devday-serpro

×