Código Limpo
@marcelotozzi | www.marcelotozzi.com
marcelotozzidelima@gmail.com | Talk
A cozinha...
O código ruim já te atrapalhou?
Por que ele foi escrito assim?
Bem provável!
Você achou que não teria
tempo pra fazer um bom
trabalho?
Seu chefe ficaria p*** se você
demorasse mais por um bom
código?
Saco cheio daquele código?
Mais coisas pra fazer?
Produto extraordinário.
Vários bugs.
Release apressado.
O código ficou uma zona!
O código ruim acabou com
a empresa!
#comofaz?
+ pessoas.
Não conhecem.
Pressão.
Quanto mais confuso, menor
a #produtividade.
piorar++
Um dia alguém vai ler seu código.
Regra do escoteiro
“Deixe a área do acampamento mais
limpa do que como você a encontrou.”
Nomes significativos
Revele
propósito!
Bons nomes todos
entendem.
Evite informações erradas
Palavras com
significado que
podem desviar do
que desejamos passar.
Um atributo accountList...
E se não for um List?
E se for uma String?
accountList.concat()?
accountList.substring()?
accou...
Nomes de classes
Use substantivos como:
Client, WikiPage, Account...
Evite palavras como:
Manager, Processor, Data, Info.....
Nomes de métodos
Use verbos:
postPayment, deletePage, save
Métodos de acessos:
get / set / is
Funções
Devem ser
pequenas
Fazer
apenas uma
coisa
•Abstração maior para menor.
•O código deve poder ser narrado.
Evite fazer coisas escondidas
DRY
Comentários
“Não insira
comentários num
código ruim,
reescreva-o.”
Comentários legais
• Licensas de software.
• //TODO’s.
• JavaDoc em APIs Públicas.
Comentários ruins
Históricos de alteração.
Comentários óbvios.
Autoria.
Evite comentários se é
possível usar um método
ou ...
Estruturas de dados
Lei de Demeter
Você manda o cachorro andar ou as patas?
#Encapsular o comportamento e a
complexidade.
Tratamento de erro
As coisas podem dar #errado!
Use unchecked exception
Aquelas que herdam
de RuntimeException.
Lembra?
Não retorne null
Lance uma exception
Lance um objeto SPECIAL CASE
Testes
O código de teste...
Limpo com nomes significativos.
Evolução, mas sem #porcaria.
Produção fica #flexível.
Os códigos de testes são tão
importantes quanto o código
de produção. Não é um
componente secundário.
Classes
1.Classes devem ser pequenas.
2.Devem ser menores ainda!!!!
Como medir o tamanho de uma classe?
RESPONSABILIDADE!
Cliente
cliente.AvaliarSePodePromoverParaPremium
AvaliadorDeClientePremium
avaliarSePodePromoverParaPremium(cliente)
Sistema
Injeção de Dependência
Desenvolvimento gradual
Esta fedendo, troque!
Obrigado!
:)
Tech Talk Buscapé - Clean Code
Tech Talk Buscapé - Clean Code
Tech Talk Buscapé - Clean Code
Tech Talk Buscapé - Clean Code
Tech Talk Buscapé - Clean Code
Tech Talk Buscapé - Clean Code
Próximos SlideShares
Carregando em…5
×

Tech Talk Buscapé - Clean Code

328 visualizações

Publicada em

Tech Talk Buscapé - Clean Code

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

Sem downloads
Visualizações
Visualizações totais
328
No SlideShare
0
A partir de incorporações
0
Número de incorporações
16
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Tech Talk Buscapé - Clean Code

  1. 1. Código Limpo @marcelotozzi | www.marcelotozzi.com marcelotozzidelima@gmail.com | Talk
  2. 2. A cozinha...
  3. 3. O código ruim já te atrapalhou? Por que ele foi escrito assim? Bem provável!
  4. 4. Você achou que não teria tempo pra fazer um bom trabalho?
  5. 5. Seu chefe ficaria p*** se você demorasse mais por um bom código?
  6. 6. Saco cheio daquele código?
  7. 7. Mais coisas pra fazer?
  8. 8. Produto extraordinário. Vários bugs. Release apressado. O código ficou uma zona! O código ruim acabou com a empresa!
  9. 9. #comofaz?
  10. 10. + pessoas. Não conhecem. Pressão. Quanto mais confuso, menor a #produtividade. piorar++
  11. 11. Um dia alguém vai ler seu código.
  12. 12. Regra do escoteiro “Deixe a área do acampamento mais limpa do que como você a encontrou.”
  13. 13. Nomes significativos
  14. 14. Revele propósito! Bons nomes todos entendem.
  15. 15. Evite informações erradas Palavras com significado que podem desviar do que desejamos passar.
  16. 16. Um atributo accountList... E se não for um List? E se for uma String? accountList.concat()? accountList.substring()? accountList.toLowerCase()?
  17. 17. Nomes de classes Use substantivos como: Client, WikiPage, Account... Evite palavras como: Manager, Processor, Data, Info... Não use verbos.
  18. 18. Nomes de métodos Use verbos: postPayment, deletePage, save Métodos de acessos: get / set / is
  19. 19. Funções
  20. 20. Devem ser pequenas Fazer apenas uma coisa
  21. 21. •Abstração maior para menor. •O código deve poder ser narrado.
  22. 22. Evite fazer coisas escondidas
  23. 23. DRY
  24. 24. Comentários
  25. 25. “Não insira comentários num código ruim, reescreva-o.”
  26. 26. Comentários legais • Licensas de software. • //TODO’s. • JavaDoc em APIs Públicas.
  27. 27. Comentários ruins Históricos de alteração. Comentários óbvios. Autoria. Evite comentários se é possível usar um método ou variável.
  28. 28. Estruturas de dados
  29. 29. Lei de Demeter Você manda o cachorro andar ou as patas? #Encapsular o comportamento e a complexidade.
  30. 30. Tratamento de erro As coisas podem dar #errado!
  31. 31. Use unchecked exception Aquelas que herdam de RuntimeException. Lembra?
  32. 32. Não retorne null Lance uma exception Lance um objeto SPECIAL CASE
  33. 33. Testes
  34. 34. O código de teste... Limpo com nomes significativos. Evolução, mas sem #porcaria. Produção fica #flexível.
  35. 35. Os códigos de testes são tão importantes quanto o código de produção. Não é um componente secundário.
  36. 36. Classes
  37. 37. 1.Classes devem ser pequenas. 2.Devem ser menores ainda!!!! Como medir o tamanho de uma classe?
  38. 38. RESPONSABILIDADE!
  39. 39. Cliente cliente.AvaliarSePodePromoverParaPremium AvaliadorDeClientePremium avaliarSePodePromoverParaPremium(cliente)
  40. 40. Sistema
  41. 41. Injeção de Dependência
  42. 42. Desenvolvimento gradual
  43. 43. Esta fedendo, troque!
  44. 44. Obrigado! :)

×