Boas práticas técnica para um código limpo (Clean Code)

14,190 views

Published on

Código que simplesmente “funciona” não é suficiente, infelizmente. Código que tem valor real e é duradouro, tem de ser “limpo”! Esta track irá abordar um pouco sobre as técnicas de Clean Code, o que é um código limpo, quais suas características e como transformar seu código ruim em um código claro e legível. Atitudes que afetam nosso comportamento como desenvolvedor e que, sem dúvidas, transformam a maneira de como desenvolvemos software.

Published in: Technology
1 Comment
56 Likes
Statistics
Notes
  • Deixe Baixar..
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
14,190
On SlideShare
0
From Embeds
0
Number of Embeds
487
Actions
Shares
0
Downloads
1
Comments
1
Likes
56
Embeds 0
No embeds

No notes for slide
  • Se um nome requer um comentário, é um nome ruim.
  • Que tipo de coisas há na lista?
    O que significa o valor 4?
  • Que tipo de coisas há na lista?
    O que significa o valor 4?
  • Programar é social.
    Nosso cérebro tem o costume de ler e não de decifrar. Você conversa com o código.
  • Blocos de edentação é indício de que está fazendo muita coisa
  • Tem que valer os bytes que consomem!
  • Pode ser levado como um gosto pessoal.
    Mas valem os padrões determinados pelo time/equipe.
  • A Lei de Demeter aborda um problema específico do acoplamento e apresenta princípios para organizar e reduzir as dependências entre classes.
  • Obriga tratamento de nulo
    Tira legibilidade do código
  • Boas práticas técnica para um código limpo (Clean Code)

    1. 1. Boas Práticas Clean Code Técnica para um código limpo Rodrigo Kono MVP, MCTS, MCPD, MCT, MCP @rodrigokono www.rodrigokono.net
    2. 2. Há duas razões pelas quais você está nesta palestra: 1. Você é um programador 2. Deseja se tornar um ainda melhor.
    3. 3. ÓTIMO! PRECISAMOS DE PROGRAMADORES MELHORES Robert C. Martin
    4. 4. The Clean Coder Robert C. Martin (Uncle Bob); Programador desde 1970; Fundador e Presidente Object Mentor Inc. Livros: Designing Object-Oriented C++ Applications using the Booch Method. 1995. Agile Software Development: Principles, Patterns and Practices. 2002. Clean Code: A Handbook of Agile Software Craftsmanship.
    5. 5. O que é Clean Code?
    6. 6. • Eficiente • Simples • Direto ao ponto • Mínimas dependências • Sem duplicação • Fácil manutenção • Padrões definidos • Fácil leitura e entendimento • Coberto de testes • Elegante Síndrome da janela quebrada
    7. 7. Que porta representa o seu código?
    8. 8. "Qualquer um consegue escrever código que um computador entende. Bons programadores escrevem código que humanos endentem“ Martin Fowler
    9. 9. Funcionar é o mínimo que se espera
    10. 10. Ah! Mas o cronograma é apertado. Não tenho tempo para frescura! Meu chefe está me pressionando! Quero mostrar produtividade.
    11. 11. Filho feio não tem pai!
    12. 12. Afinal, de quem é a culpa?
    13. 13. É nossa!
    14. 14. Como mensurar a qualidade de um código?
    15. 15. OK! Vamos ao que interessa
    16. 16. NOMES SIGNIFICATIVOS
    17. 17. Nomes significativos int d; // tempo transcorrido em dias int tempoTranscorridoEmDias; int diasDesdeCriacaoDoArquivo; int diasDesdeModificacaoDoArquivo; int idadeDoArquivoEmDias;
    18. 18. Use nomes que revelem a intenção
    19. 19. Nomes significativos public List<int> obter() { int[] x = new int[3]; List<int> lista1 = new List<int>(); for (int i = 0; i < lista; i++) { if (x[0] == 4) { lista1.Add(x[0]); } } return lista1; } public List<int> obtemDiasMarcados() { int[] diaMarcado = new int[3]; List<int> diasMarcados = new List<int>(); for (int dia = 0; dia < mes; dia++) { if (diaMarcado[STATUS] == MARCADO) { diasMarcados.Add(diaMarcado[STATUS]); } } return diasMarcados; }
    20. 20. Nomes significativos public List<int> obtemDiasMarcados() { int[] diaMarcado = new int[3]; List<Dia> diasMarcados = new List<Dia>(); foreach (Dia dia in mes) { if (dia.marcado) { diasMarcados.Add(dia); } } return diasMarcados; }
    21. 21. Use nomes pronunciáveis
    22. 22. Nomes significativos class DtaRcrd102 { private DateTime gerdmahms; private DateTime moddmahms; private string pszqint = "102"; } class Cliente { private DateTime gerarDataHora; private DateTime modificarDataHora; private string idRegistro = "102"; }
    23. 23. Use nomes buscáveis
    24. 24. Nomes significativos const int DIAS_DE_TRABALHO_POR_SEMANA = 5; int soma = 0; int diasReaisDeTrabalho = 4; for (int j = 0; j < NUMERO_DE_TAREFAS; j++) { int tarefasPorDia = trabalhoEstimado[j] * diasReaisDetrabalho; int taredasPorSemana = (dias / DIAS_DE_TRABALHO_POR_SEMANA); soma += taredasPorSemana; } for (int j = 0; j < 30; j++) { s = (t[j]*4)/5; }
    25. 25. Nomeando classes e métodos
    26. 26. Nomes significativos Classes representadas por substantivos ex: Cliente, Perfil, Estoque, etc Métodos representadas por verbos ou frases verbais ex: enviarPagamento, salvar, etc.
    27. 27. FUNÇÕES
    28. 28. Seja pequeno
    29. 29. Funções • Menos é mais! • Extraia trechos em métodos privados. • Lembre-se dos nomes significativos • Vá direto ao ponto.
    30. 30. Funções
    31. 31. Faça uma coisa só!
    32. 32. Funções • Repare a endentação (sim, é assim que escreve) • Muitos níveis ~= muita responsabilidade • O método deve fazer uma única coisa, e bem! • Está fazendo mais de uma coisa? Extraia.
    33. 33. Leia o código de cima pra baixo
    34. 34. Funções • Seu código deve ser lido como uma narrativa • Temos sujeitos, verbos e predicados • Narrativas são frases em ordem coerente • Lembre-se disto ao extrair em métodos privados;
    35. 35. Funções • Muitos argumentos = code smell • Existem algumas regras para a quantidade de argumentos • Argumentos booleanos, em geral, não são bons.
    36. 36. Funções
    37. 37. DRY (Don’t Repeat Yourself)
    38. 38. COMENTÁRIOS
    39. 39. Comentários não ajudam um código sujo!
    40. 40. Comentários • Em geral, servem para explicar um código ruim. • Um bom código é auto documentado. • Extraia para um método que faça o que diz!
    41. 41. Comentários aceitáveis
    42. 42. Comentários • Comentários sobre licença (direitos de uso de uma lib, por exemplo) • Comentários informativos • Necessidade de explicação de negócio
    43. 43. Comentários ruins
    44. 44. Comentários • Por falta do que escrever • Redundantes • Documentação em APIs não públicas • Dizendo algo que o próprio código deveria dizer • Código comentado =S
    45. 45. Comentários
    46. 46. FORMATAÇÃO
    47. 47. O que vale é a regra do time
    48. 48. OBJETOS E ESTRUTURA DE DADOS
    49. 49. Abstração de dados
    50. 50. Objetos e estrutura de dados
    51. 51. Objetos e estrutura de dados
    52. 52. A lei de Demeter
    53. 53. Objetos e estrutura de dados Um método M de uma classe C só conhece: • Métodos de C • Objetos criados por M • Objetos passados como argumentos para M • Objetos em variáveis de instâncias de C
    54. 54. Demeter Law C M
    55. 55. TRATAMENTO DE ERRO
    56. 56. Exceções ao invés de código de erro.
    57. 57. Tratamento de erro
    58. 58. Tratamento de erro
    59. 59. Tratamento de exceção é uma das coisas que um método ou função faz
    60. 60. Não use exceções genéricas
    61. 61. Não retorne null
    62. 62. Tratamento de erro • Obriga o uso de if • Pode disparar NullPointerException • Considere: Lançar exceção ou retornar um objeto especial
    63. 63. Não passe null
    64. 64. REGRA DOS ESCOTEIROS Deixe a área do acampamento mais limpa do que como você a Encontrou.
    65. 65. Não deixe acumular problemas!
    66. 66. Código ruim cheira mal... Torna o seu trabalho lento e desgastante com o passar do tempo Pode arruinar seu projeto, carreira, empresa... Fique atento.
    67. 67. Falar é fácil! O desafio é criar um código de qualidade. Portanto, falar é o primeiro passo de melhoria.
    68. 68. Using References; Gustavo Barbosa http://www.slideshare.net/gustavocsb Hendrik Ebel http://www.slideshare.net/hebel Thiago Faria de Andrade http://www.slideshare.net/thiagofa
    69. 69. END contato@rodrigokono.net

    ×