Clean code

101 visualizações

Publicada em

Apresentação sobre o livro clean code

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

Nenhuma nota no slide

Clean code

  1. 1. Agenda ● Motivação ● Nomes significativos ● Funções ● Comentários ● Formatação ● Tratamento de exceção ● Testes de unidade
  2. 2. Era uma vez em 1980...
  3. 3. ● Maiores intervalos entre lançamentos ● Bugs não eram corrigidos ● Cada vez mais travamentos
  4. 4. Alguns anos depois...
  5. 5. O custo de ter um código confuso
  6. 6. Por que não fazer de novo? Afinal somos melhores do que quando começamos
  7. 7. Sem comentários
  8. 8. Escolhendo nomes significativos
  9. 9. Um bom nome precisa responder 3 perguntas: 1. Por que existe? 2. O que faz? 3. Como é usado?
  10. 10. Use nomes que revelem seu proposito
  11. 11. Cuidado para não passar informações erradas!
  12. 12. Evite nomes sem significado
  13. 13. Outro exemplo
  14. 14. Use palavras pronunciáveis
  15. 15. Notação Húngara
  16. 16. Notação Húngara
  17. 17. Funções
  18. 18. Funções devem ser: ● Pequenas ● Fazer apenas uma coisa ● Ser bem nomeadas ● Devem ser lidas de cima para baixo ● Extrair trechos para funções menores ● DRY
  19. 19. Cuidado com a quantidade de parâmetros Qual é a quantidade ideal de parâmetros? ZERO
  20. 20. Mônades ● Geralmente perguntam ou transformam algo ● Evitar retornos void ● Evitar parâmetros lógicos
  21. 21. Díades ● Sempre tentar transformá-la em mônade ● Parâmetros deve fazer parte do mesmo valor ● Cuidar a ordem dos parâmetros
  22. 22. Tríades Problemas: + pausa + ignoração + dificuldade de manter a ordem
  23. 23. Comentários
  24. 24. Comentários geralmente: ● Mentem ● Desatualizam ● Imprecisos Porque o código muda! Porque o código muda! Porque o código muda!
  25. 25. Uso de comentários ● Esclarecimento ● Alerta de consequência ● JavaDoc em API pública ● Comentário legal ● TODO ● Redundantes ● Longos ● HTML ● Explicando código ● Ao lados de cada chave ● JavaDoc em API NÃO pública ● Código comentado
  26. 26. Formatação
  27. 27. Alguns cuidados: ● Manter o código bem identado ● Distância vertical ● Função dependente ● Linha de no máximo 120 caracteres ● Classes devem tem o minimo de linhas possível
  28. 28. Tratamento de exceções
  29. 29. Exceções ● Usar exceções em vez de retornar código de erro ● Não pode obscurecer a lógica ● Criar testes que forcem a exceção ● Use exceções não verificadas ● Lance exceções com um contexto
  30. 30. Não retorne NULL
  31. 31. Não retorne NULL Diminui o número de NullPointerException
  32. 32. Não passe NULL
  33. 33. Testes de Unidade
  34. 34. As 3 leis do TDD ● Você não pode escrever código de produção a menos que ele tenha um teste de unidade que falha. ● Você não pode escrever mais teste de unidade que o suficiente para falhar; e erros de compilação são falhas. ● Você não pode escrever mais que o suficiente, para o código de produção passar em um teste de unidade.
  35. 35. Vantagens ● flexibilidade ● código limpo ● passível de mudanças ● feedback ● segurança ● maior produtividade
  36. 36. Testes = Código
  37. 37. Classes
  38. 38. Como elas devem ser? ● Possuir nomes descritivos ● Pequenas ● SRP ● Alta coesão
  39. 39. O que é SRP?
  40. 40. O que é alta coesão?

×