Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Boas Práticas
Clean Code
Técnica para um código limpo
Rodrigo Kono
MVP, MCTS, MCPD, MCT, MCP
@rodrigokono
www.rodrigokono....
Há duas razões pelas quais
você está nesta palestra:
1. Você é um programador
2. Deseja se tornar um ainda melhor.
ÓTIMO! PRECISAMOS DE
PROGRAMADORES MELHORES
Robert C. Martin
The Clean Coder
Robert C. Martin (Uncle Bob); Programador desde 1970;
Fundador e Presidente Object Mentor Inc.
Livros:
Des...
O que é Clean Code?
• Eficiente
• Simples
• Direto ao ponto
• Mínimas dependências
• Sem duplicação
• Fácil manutenção
• Padrões definidos
• F...
Que porta representa o seu código?
"Qualquer um consegue escrever
código que um computador entende.
Bons programadores escrevem
código que humanos endentem“
...
Funcionar é o mínimo que se espera
Ah! Mas o cronograma é
apertado.
Não tenho tempo para
frescura!
Meu chefe está me
pressionando!
Quero mostrar produtividad...
Filho feio não tem pai!
Afinal, de quem é a culpa?
É nossa!
Como mensurar a
qualidade de um código?
OK! Vamos ao que interessa
NOMES SIGNIFICATIVOS
Nomes significativos
int d; // tempo transcorrido em dias
int tempoTranscorridoEmDias;
int diasDesdeCriacaoDoArquivo;
int ...
Use nomes que revelem a intenção
Nomes significativos
public List<int> obter()
{
int[] x = new int[3];
List<int> lista1 = new List<int>();
for (int i = 0; ...
Nomes significativos
public List<int> obtemDiasMarcados()
{
int[] diaMarcado = new int[3];
List<Dia> diasMarcados = new Li...
Use nomes pronunciáveis
Nomes significativos
class DtaRcrd102
{
private DateTime gerdmahms;
private DateTime moddmahms;
private string pszqint = "...
Use nomes buscáveis
Nomes significativos
const int DIAS_DE_TRABALHO_POR_SEMANA = 5;
int soma = 0;
int diasReaisDeTrabalho = 4;
for (int j = 0;...
Nomeando classes e métodos
Nomes significativos
Classes
representadas por substantivos
ex: Cliente, Perfil, Estoque, etc
Métodos
representadas por ve...
FUNÇÕES
Seja pequeno
Funções
• Menos é mais!
• Extraia trechos em métodos privados.
• Lembre-se dos nomes significativos
• Vá direto ao ponto.
Funções
Faça uma coisa só!
Funções
• Repare a endentação (sim, é assim que escreve)
• Muitos níveis ~= muita responsabilidade
• O método deve fazer u...
Leia o código de cima pra baixo
Funções
• Seu código deve ser lido como uma
narrativa
• Temos sujeitos, verbos e predicados
• Narrativas são frases em ord...
Funções
• Muitos argumentos = code smell
• Existem algumas regras para a
quantidade de argumentos
• Argumentos booleanos, ...
Funções
DRY (Don’t Repeat Yourself)
COMENTÁRIOS
Comentários não ajudam
um código sujo!
Comentários
• Em geral, servem para explicar um código ruim.
• Um bom código é auto documentado.
• Extraia para um método ...
Comentários aceitáveis
Comentários
• Comentários sobre licença (direitos de
uso de uma lib, por exemplo)
• Comentários informativos
• Necessidade...
Comentários ruins
Comentários
• Por falta do que escrever
• Redundantes
• Documentação em APIs não públicas
• Dizendo algo que o próprio cód...
Comentários
FORMATAÇÃO
O que vale é a regra do time
OBJETOS E ESTRUTURA
DE DADOS
Abstração de dados
Objetos e estrutura de dados
Objetos e estrutura de dados
A lei de Demeter
Objetos e estrutura de dados
Um método M de uma classe C só conhece:
• Métodos de C
• Objetos criados por M
• Objetos pass...
Demeter Law
C
M
TRATAMENTO DE ERRO
Exceções ao invés de
código de erro.
Tratamento de erro
Tratamento de erro
Tratamento de exceção é uma das
coisas que um método ou função faz
Não use exceções genéricas
Não retorne null
Tratamento de erro
• Obriga o uso de if
• Pode disparar NullPointerException
• Considere: Lançar exceção ou retornar um ob...
Não passe null
REGRA DOS ESCOTEIROS
Deixe a área do acampamento
mais limpa do que como você a
Encontrou.
Não deixe acumular problemas!
Código ruim
cheira mal...
Torna o seu trabalho
lento e desgastante
com o passar do
tempo
Pode arruinar seu
projeto, carrei...
Falar é fácil!
O desafio é criar um código de
qualidade.
Portanto, falar é o primeiro passo de melhoria.
Using References;
Gustavo Barbosa
http://www.slideshare.net/gustavocsb
Hendrik Ebel
http://www.slideshare.net/hebel
Thiago...
END
contato@rodrigokono.net
Boas práticas técnica para um código limpo (Clean Code)
Boas práticas técnica para um código limpo (Clean Code)
Prochain SlideShare
Chargement dans…5
×

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

21 059 vues

Publié le

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.

Publié dans : Technologie
  • Deixe Baixar..
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici

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

×