Refinamento e boas práticas de programação

5,841 views
5,703 views

Published on

Palestra minstrada por Luiz Artur - CESAR

2 Comments
17 Likes
Statistics
Notes
No Downloads
Views
Total views
5,841
On SlideShare
0
From Embeds
0
Number of Embeds
300
Actions
Shares
0
Downloads
0
Comments
2
Likes
17
Embeds 0
No embeds

No notes for slide

Refinamento e boas práticas de programação

  1. 1. Refinamento e boas práticas de programaçãoLuiz Artur Botelho da Silva – labotelho@gmail.comPós-gradução Engenharia de Software - FBVEngenheiro de Sistemas – C.E.S.A.R
  2. 2. Agenda Código Limpo; Como transformar um código ruim em um bom; Programação Geral;
  3. 3. Código Limpo
  4. 4. Qual o melhor caminho?
  5. 5. Dificuldades de se ter umcódigo limpo 1. Prazos apertados; 2. Pressa para lançar o produto no mercado; 3. Cronograma extenso.“Uma bagunça que funciona é melhor do que nada.” (Robert C. Martin)
  6. 6. Custo de ter um códigoconfuso
  7. 7. Solução para produtividade:Lei de Brooks: "Incluir mais gente emum projeto atrasado vai atrasá-lo aindamais"
  8. 8. O que é código limpo?“Um código limpo é simples e direto. Ele é tão bem legível quanto uma prosa bem escrita.“ Fonte: Grady Booch, Autor do livro: Aplicações com design e análise orientado a objeto.
  9. 9. O que é código limpo? "Além do seu criador, um desenvolvedor pode ler e melhorar um código limpo.“ Fonte: Dave Thomas, fundador da estratégia Eclipse.
  10. 10. Vantagens de ter o códigolimpo1. Simplicidade;2. Clareza;3. Flexibilidade;4. Fácil manutenção;5. Boa performance;6. ...
  11. 11. Como se aprende a gerarcódigo limpo?Não há uma metodologia especifica.Solução:1. Ler vários livros;2. Aprender com a experiência dos outros.
  12. 12. Como transformar umcódigo ruim em umbom
  13. 13. Nomes Significativos Código Ruim Código Bom
  14. 14. Nomes Significativos Código Ruim Código Bom
  15. 15. Nomes Significativos Código Ruim Sugestão: Usar fontes distintas com propósito de realçar mais as diferenças.
  16. 16. Nomes Significativos Código Ruim Sugestão: Faça distinção dos nomes.
  17. 17. Nomes Significativos Código Ruim Código Bom
  18. 18. Funções Devem ser pequenas (no máximo 20 linhas); Devem fazer apenas uma coisa por função; Devem ter poucos parâmetros de entrada;
  19. 19. Funções (Vários Parâmetros) Código Ruim Código Bom
  20. 20. Funções Prefira exceções a retorno de códigos de erro; Evite repetição de código; Manter blocos e indentação (no máximo em 2 níveis);
  21. 21. Construtores (Vários Parâmetros) Uso do padrão construtor telescópio; Uso do padrão javaBeans; Uso de objeto criador;
  22. 22. Construtores (Vários Parâmetros) Código RuimCriando uma instância da classe acima:
  23. 23. Uso do padrão construtor telescópio Código BomCriando uma instância da classe acima:
  24. 24. Desvantagens O leitor é tentado a entender todos os parâmetros; Longa seqüência de parâmetros digitadas pode causar erros;
  25. 25. Uso do padrão javaBeans Código BomCriando uma instância da classe acima:
  26. 26. Desvantagens Um javaBean pode iniciar já em um estado inconsistente; O padrão javaBean impossibilita que uma classe seja imutável;
  27. 27. Uso de objeto criador Código Bom
  28. 28. Uso de objeto criador Criando uma instância default de um objeto criador: Criando uma instância setando parâmetros opcionais em um objeto criador:
  29. 29. Uso de objeto criador Garante a consistência dos dados conforme o padrão de construtor telescópio; Garante a legibilidade do padrão javaBeans;
  30. 30. Comentários Não usar comentários Javadocs para métodos privados; Evitar comentários excessivos; Marcar com comentário ToDo no código possíveis pontos de modificação;
  31. 31. Comentários Alertar sobre conseqüências; Comentários informativos sobre o funcionamento da função; Evitar comentários redundantes; Sempre colocar o comentário junto ao código que ele descreve;
  32. 32. Objetos Evite a criação de objetos desnecessários; Prefira primitivas simples a primitivas encaixotadas; Elimine referências de objetos obsoletas; Evite finalizadores;
  33. 33. Evite a criação de objetos desnecessários; Código Ruim Código Bom
  34. 34. Evite a criação de objetos desnecessários; Código Ruim  Código Bom
  35. 35. Evite a criação de objetosdesnecessários; Vantagens: 1. Reutilização do objeto em outros pontos do código; 2. Reutilizar um objeto é mais rápido que criar um novo; Desvantagem: 1. Objeto pode nunca está pronto para ser coletado;
  36. 36. Diferença entre primitivas simples e encaixotadas Primitivas simples:  Primitivas encaixotadas: 1. Possui apenas os 1. Possui identidade e seus seus valores; valores, ou seja, 2 2. Mas eficiente; instancias desse tipo 3. Possui apenas podem ter o mesmo valor valores funcionais; com instancias diferentes; Ex.: int i = 2; 2. Menos eficiente; 3. Pode ter tanto valores funcionais quanto não funcionais; Ex.: Integer i = 2; OU Integer i = null;
  37. 37. Prefira primitivas simples a primitivas encaixotadas O que acontece com a saída desse código?
  38. 38. Prefira primitivas simples a primitivas encaixotadas Código Ruim Código Bom
  39. 39. Quem é mais rápido? Código Ruim Código Bom
  40. 40. Resposta: Mudar Long para long na declaração de sum reduz o tempo de execução de 43 segundos para 6,8 segundos. Máquina AMD Opteron 170 dual-core de 2,2 GHz e 2 GB de RAM
  41. 41. Elimine referências de objetos obsoletas Código Ruim
  42. 42. Elimine referências de objetos obsoletas Código Bom
  43. 43. Atenção! Problemas de OutOfMemoryError podem ser provocados caso não se elimine as referências obsoletas;
  44. 44. Evite finalizadores Código Ruim
  45. 45. Evite finalizadores Finalizadores são imprevisíveis e com isso não se sabe a hora que eles serão executados; Finalizadores provocam perda de desempenho;
  46. 46. Evite finalizadores Conclusão: A inclusão de um finalizador aumenta o tempo para 2400 ns, deixando o processo de criação e destruição de objetos 430 vezes mais lento.Máquina AMD Opteron170 dual-core de 2,2GHz e 2 GB de RAM
  47. 47. Programação Geral
  48. 48. Programação Geral Reduza o escopo de variáveis locais, ou seja, declare ela apenas onde for usada; Prefira loops for a loops while;
  49. 49. Programação Geral Evite float e double a respostas exatas; Cuidado com o desempenho da concatenação de strings;
  50. 50. Prefira loops for a loops while Código Ruim
  51. 51. Prefira loops for a loopswhile Com loop “for” não há motivo para o uso de nomes de variáveis diferentes nos dois loops; A variável alocada no loop “for” é liberada logo após terminar o seu delimitador de escopo; Obs.: Tanto o loop “for” quanto o loop “while” apresentam o mesmo desempenho. Fonte: http://stackoverflow.com/questions/1165457/java-for-loop-vs-while-loop-performance-difference
  52. 52. Prefira loops for a loops whileUsando o comando “javap” podemos ver que os 2 loopssão convertidos para o mesmo código interpretado pelaJVM.
  53. 53. Cuidado com o desempenho da concatenação de strings Código Ruim
  54. 54. Cuidado com o desempenho da concatenação de strings Código Bom
  55. 55. Dúvidas
  56. 56. Referências Bibliográficas  ROBERT C. MARTIN. Código Limpo: habilidades práticas do Agile Software, Alta Books, 2011.
  57. 57. Referências Bibliográficas  Joshua Bloch. Java Efetivo, 2ª Edição, Alta Books 2010.

×