Princípios Básicos para
Desenvolvedores
while(!(succeed=try()))
Guilherme Reis
Agenda
• Dicas para iniciantes;
• Mau cheiro;
• Porque se importar com o código;
• Código limpo;
• Princípios básicos de d...
Programação...
Programação é lógica,
não magia negra
• “Eu gosto de programar, só não gosto de lógica” (Ex-
aluno de Computação)
Antes de codificar, pense
no que quer/precisa fazer
Não funcionará na primeira vez!
Provavelmente nem na segunda ou terceira;
Mas quando funciona...
Trabalho em equipe
Maus cheiros
• Primeiramente usado por Kent Beck e citado por Martin
Fowler;
• Indicação superficial de alerta à problemas...
Exemplos
• Classes e métodos/funções enormes;
• Código ilegível;
• Códigos repetidos;
• Códigos redundantes;
• Métodos/Fun...
Baixa Coesão
Alto Acoplamento
• Forte dependência entre componentes;
• Dificulta mudanças;
• Dificulta reaproveitamento de código;
Alto Acoplamento
Fases de um projeto
• Tudo é muito bonito, limpo, elegante e convincente;
• Tudo funciona e as atividades são cumpridas como se
esperava;
• Tu...
O importante é
funcionar...
• O código começa a “ter um cheiro desagradável”
• No começo nem parece tão ruim;
• Uma verrug...
A culpa não é minha...
“Tudo muda, tudo
sempre mudará...”
• Bugs começam a aparecer;
• Mudanças nos requisitos começam a surgir;
• Puxadinhos (Ex...
Como prevenir?
• Mínimo:
• Se importe com o código gerado;
• Escrevendo um “código limpo”;
• Preocupando-se com o design d...
Por que devo me
importar?
Por que devo me
importar?
Ciclo de um projeto
Prevenção
Por que devo me
importar?
• Não é só pelaos 20 centavos estética:
• É pelo TEMPO gasto!
Como assim tempo?
• O que fazemos em nosso tempo? Sim, os 20% que sobram após o
coffe break, pipi break, tea break, brief ...
Mais e o código?
• Similar aos bancos de dados:
• Taxa de leitura:escrita de 10:1;
• Não fazemos UPDATE e sim várias sequê...
Tempo é dinheiro!
• Como reduzir custos através do código? Enchendo o projeto de
estagiários?
• Tempo de leitura/entendime...
Pensando bem...
Código limpo
Humanos <- Código
Máquinas <- 01101001010
Por falar em nome...
Nomenclatura
• Sim, o nome importa!
• O propósito de um nome é revelar intenção/objetivo;
• Depois do ctrl+c e ctrl+v, o q...
Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?
Nomenclatura
• Qual componente do formulário será mostrado ou
escondido?
O que este código faz?
Melhor?
E assim?
O que mudou?
• Nomes que revelam intenção:
• flaggedCells no lugar de list
• cell no lugar de x
• Remoção de números mágic...
Princípios básicos
design
• 5 princípios de boas práticas vindas de décadas de experiência
em engenharia de software;
• [S...
S – Single Responsibility
S – Single Responsibility
• Uma classe/método deve ter apenas uma razão para ser
modificado(a);
• Menor impacto em mudança...
S – Single Responsibility
S – Single Responsibility
O - Open Closed
• Fechado para edições;
• Aberto para extensões;
O - Open Closed
O - Open Closed
L - Liskov substitution
• As classes derivadas não devem ser mais fracas e nem
mais fortes que sua base
L - Liskov substitution
Customer
Gold Silver Guest
L - Liskov substitution
L - Liskov substitution
I - Interface Segregation
• Melhor ter várias interfaces pequenas para propósitos
específicos
• Do que interfaces genérica...
I - Interface Segregation
I - Interface Segregation
D - Dependency inversion
• Dependa de abstrações, não de detalhes concretos
D - Dependency inversion
D - Dependency inversion
Resultado
Perguntas
Interessado?
OBRIGADO!
• Skype: guitoper
• Twitter: @guitoper
• LinkedIn: br.linkedin.com/pub/guilherme-reis/22/5a2/a44/
• Slides: http...
Próximos SlideShares
Carregando em…5
×

Princípios Básicos para Desenvolvedores

578 visualizações

Publicada em

Introdução aos temas "Clean Code" e "Princípios de Design S.O.L.I.D"

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
578
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Princípios Básicos para Desenvolvedores

  1. 1. Princípios Básicos para Desenvolvedores while(!(succeed=try())) Guilherme Reis
  2. 2. Agenda • Dicas para iniciantes; • Mau cheiro; • Porque se importar com o código; • Código limpo; • Princípios básicos de design;
  3. 3. Programação...
  4. 4. Programação é lógica, não magia negra • “Eu gosto de programar, só não gosto de lógica” (Ex- aluno de Computação)
  5. 5. Antes de codificar, pense no que quer/precisa fazer
  6. 6. Não funcionará na primeira vez! Provavelmente nem na segunda ou terceira;
  7. 7. Mas quando funciona...
  8. 8. Trabalho em equipe
  9. 9. Maus cheiros • Primeiramente usado por Kent Beck e citado por Martin Fowler; • Indicação superficial de alerta à problemas mais profundos no sistema; • Não são bugs, mas falhas no design: • Atraso no desenvolvimento • Risco de bugs e falhas no futuro • “Qualquer nariz” consegue identificar;
  10. 10. Exemplos • Classes e métodos/funções enormes; • Código ilegível; • Códigos repetidos; • Códigos redundantes; • Métodos/Funções com vários parâmetros; • Baixa coesão*; • Alto acoplamento*;
  11. 11. Baixa Coesão
  12. 12. Alto Acoplamento • Forte dependência entre componentes; • Dificulta mudanças; • Dificulta reaproveitamento de código;
  13. 13. Alto Acoplamento
  14. 14. Fases de um projeto
  15. 15. • Tudo é muito bonito, limpo, elegante e convincente; • Tudo funciona e as atividades são cumpridas como se esperava; • Tudo flui conforme o cronograma... No começo...
  16. 16. O importante é funcionar... • O código começa a “ter um cheiro desagradável” • No começo nem parece tão ruim; • Uma verruga aqui, uma gambiarra ali, mais tudo ainda parece bonito e funcional; • Não há tempo para organização e melhorias; • “Em time que está ganhando não se meche”;
  17. 17. A culpa não é minha...
  18. 18. “Tudo muda, tudo sempre mudará...” • Bugs começam a aparecer; • Mudanças nos requisitos começam a surgir; • Puxadinhos (Extensões) se tornam necessários; • Novos campos e botões são adicionados; • Então o código começa a apodrecer e consequentemente, o “cheiro” fica insuportável;
  19. 19. Como prevenir? • Mínimo: • Se importe com o código gerado; • Escrevendo um “código limpo”; • Preocupando-se com o design do software; • Melhor ainda: • Fazer revisões de códigos com a equipe; • Escrevendo testes automatizados; • Realizando refactors ao identificar maus cheiros no software;
  20. 20. Por que devo me importar?
  21. 21. Por que devo me importar?
  22. 22. Ciclo de um projeto
  23. 23. Prevenção
  24. 24. Por que devo me importar? • Não é só pelaos 20 centavos estética: • É pelo TEMPO gasto!
  25. 25. Como assim tempo? • O que fazemos em nosso tempo? Sim, os 20% que sobram após o coffe break, pipi break, tea break, brief break, etc. • Planejamos mudanças; • Lemos (e muito) código; • Atuamos nos planos; • Codificação de verdade? Não muito...
  26. 26. Mais e o código? • Similar aos bancos de dados: • Taxa de leitura:escrita de 10:1; • Não fazemos UPDATE e sim várias sequências de GET e PUT; • Nosso cérebro não é um bom cache;
  27. 27. Tempo é dinheiro! • Como reduzir custos através do código? Enchendo o projeto de estagiários? • Tempo de leitura/entendimento; • Seus colegas lerão seus códigos inúmeras vezes • Entender um módulo leva 2 horas ou 5 minutos? • Tempo de escrita/adaptação/manutenção; • O software irá mudar: fato; • Quão fácil será esta mudança? • Quanto do código será reaproveitado em outro projeto?
  28. 28. Pensando bem...
  29. 29. Código limpo
  30. 30. Humanos <- Código Máquinas <- 01101001010
  31. 31. Por falar em nome...
  32. 32. Nomenclatura • Sim, o nome importa! • O propósito de um nome é revelar intenção/objetivo; • Depois do ctrl+c e ctrl+v, o que mais utilizamos em IDEs é o ctrl+SPACE
  33. 33. Nomenclatura • Qual componente do formulário será mostrado ou escondido?
  34. 34. Nomenclatura • Qual componente do formulário será mostrado ou escondido?
  35. 35. O que este código faz?
  36. 36. Melhor?
  37. 37. E assim?
  38. 38. O que mudou? • Nomes que revelam intenção: • flaggedCells no lugar de list • cell no lugar de x • Remoção de números mágicos: • cell[STATUS_VALUE] no lugar de x[0] • Abstração de tipo de dados: • Cell cell no lugar de int[] cell
  39. 39. Princípios básicos design • 5 princípios de boas práticas vindas de décadas de experiência em engenharia de software; • [S]ingle Responsibility Principle [O]pen/Closed Principle [L]iskov Substitution Principle [I]nterface Segregation Principle [D]ependency Inversion Principle
  40. 40. S – Single Responsibility
  41. 41. S – Single Responsibility • Uma classe/método deve ter apenas uma razão para ser modificado(a); • Menor impacto em mudanças; • Reaproveitamento de código; • Alta coesão;
  42. 42. S – Single Responsibility
  43. 43. S – Single Responsibility
  44. 44. O - Open Closed • Fechado para edições; • Aberto para extensões;
  45. 45. O - Open Closed
  46. 46. O - Open Closed
  47. 47. L - Liskov substitution • As classes derivadas não devem ser mais fracas e nem mais fortes que sua base
  48. 48. L - Liskov substitution Customer Gold Silver Guest
  49. 49. L - Liskov substitution
  50. 50. L - Liskov substitution
  51. 51. I - Interface Segregation • Melhor ter várias interfaces pequenas para propósitos específicos • Do que interfaces genéricas enormes
  52. 52. I - Interface Segregation
  53. 53. I - Interface Segregation
  54. 54. D - Dependency inversion • Dependa de abstrações, não de detalhes concretos
  55. 55. D - Dependency inversion
  56. 56. D - Dependency inversion
  57. 57. Resultado
  58. 58. Perguntas
  59. 59. Interessado?
  60. 60. OBRIGADO! • Skype: guitoper • Twitter: @guitoper • LinkedIn: br.linkedin.com/pub/guilherme-reis/22/5a2/a44/ • Slides: http://pt.slideshare.net/guitoper/princpios-bsicos- para-desenvolvedores

×