Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Código Limpo (Clean Code) - FATEC DevDay 2021

Código Limpo (Clean Code) - FATEC DevDay 2021

Dicas para escrever código manutenível.
Slides da palestra sobre Código Limpo (Clean code), realizada pela de FATEC Mogi Mirim.

Roger Albino

May 22, 2021
Tweet

More Decks by Roger Albino

Other Decks in Programming

Transcript

  1. Clean Code (Código limpo) Dicas para escrever código manutenível.

  2. Roger Albino - Desenvolvedor há 8 anos - Trabalhei na

    Kazap como Engenheiro de Software - Desenvolvedor Front-end no Grupo Boticário - Mentor no Programa Desenvolve GB @rogeralbinoi - Twitter, GitHub, Speaker deck…
  3. • Temos um grande desafio: construir o maior e melhor

    ecossistema de beleza do mundo. • Pra isso, em 2019 decidimos que o Grupo Boticário deveria se tornar líder em tecnologia e experiência. • Em um ano, dobramos de tamanho, e em 2021 dobraremos novamente.
  4. Acesse grupoboticario.gupy.io/ e conheça as oportunidades! Que tal reinventar o

    futuro da beleza com a gente?
  5. Código Limpo (Clean Code) Livro por Robert C.Martin (Uncle Bob)

    • Livro com ensinamentos para escrever código de qualidade. Imagem retirada de: https:/ /www.amazon.com.br/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM
  6. • Eu já escrevi código ruim • Você vai escrever

    muito código ruim ainda… • Tá tudo bem! • Faz parte do aprendizado Se você está começando… Não se assuste!
  7. O que é um código bom?

  8. • Mas que diabos é isso? • Nossa, mas que

    diabos é isso? • Mas que diabos é isso? • Cara, mas que diabos é isso? • Nossa, mas que diabos é isso? • Ahn… que diabos é isso? • Mas que diabos é isso? Porta da esquerda (Código bom) Porta da direita (Código ruim) A única mensuração válida para qualidade de código: Mas que diabos é isso / minuto.
  9. Saber o que é um código bom não te faz

    escrever um código bom. O Nascimento de Vênus (1484–1486), Sandro Botticelli - Imagem retirada de: https:/ /www.revistabula.com/12033-as-10-obras-de-arte-mais-famosas-da-historia/
  10. Um Código bom realmente importa? Se tá funcionando já tá

    bom não tá?
  11. Um código bom realmente importa? • Somos autores, uma boa

    comunicação é nossa responsabilidade • Outras pessoas vão ler o seu código • Você também vai ter que ler o seu código • Passamos a maior parte do tempo dando manutenção em código existente • Perdemos horas e recursos importantes devido a um código mal escrito
  12. Produtividade / Tempo decorrido do projeto Produtividade 0 25 50

    75 100 Tempo decorrido do projeto Abril Maio Junho Julho Agosto Um código ruim reduz a produtividade do time com o passar do tempo.
  13. Na real você tá queimando dinheiro!

  14. • Nomeamos coisas o tempo todo (variáveis, funções, parâmetros, classes,

    pacotes, arquivos, pastas) • Escolha nomes que revelem o seu propósito • Escolher bons nomes leva tempo, mas economiza um tempão no futuro. • Quando encontrar nomes melhores, troque-os Nomes
  15. Dar nomes é muito difícil

  16. • Use nomes que revelem o seu propósito Nomes

  17. • Use nomes que revelem o seu propósito • Evite

    dicas erradas Nomes
  18. Nomes • Use nomes que revelem o seu propósito •

    Evite dicas erradas
  19. Nomes • Use nomes que revelem o seu propósito •

    Evite dicas erradas • Evite números mágicos
  20. Nomes • Use nomes que revelem o seu propósito •

    Evite dicas erradas • Evite números mágicos • Evite usar apenas letras (x, y, z, a, b, c)
  21. Nomes • Use nomes que revelem o seu propósito •

    Evite dicas erradas • Evite números mágicos • Evite usar apenas letras (x, y, z, a, b, c) • Evite siglas e abreviações (a menos que todos conheçam tipo API)
  22. Nomes • Evite contexto desnecessário

  23. Nomes • Evite contexto desnecessário • Evite números mágicos

  24. Nomes • Evite contexto desnecessário • Evite números mágicos •

    Crie nomes buscáveis e pronunciáveis
  25. Classes • Nome de classes: Substantivos (Account, Cart, Shipping) •

    Nome de Métodos: Verbos (addItem, removeItem, getProductList)
  26. Funções / Métodos • Devem ter apenas uma responsábilidade (Fazer

    apenas uma coisa)
  27. Funções / Métodos • Devem ter apenas uma responsábilidade (Fazer

    apenas uma coisa) • Devem ser pequenas (Se a função está grande, talvez ela esteja fazendo mais do que deveria)
  28. Funções / Métodos • Blocos de identação (if, else, while),

    devem ter apenas uma linha (possivelmente chamando outra função)
  29. Funções / Métodos • Blocos de identação (if, else, while),

    devem ter apenas uma linha (possivelmente chamando outra função) • Não tenha medo de criar nomes grandes (o nome da função deve descrever o que ela faz)
  30. Funções / Métodos • Evite listas grandes de parâmetros (mais

    que dois já é muito)
  31. Funções / Métodos • Evite listas grandes de parâmetros (mais

    que dois já é muito)
  32. Funções / Métodos • Evite código duplicado

  33. Funções / Métodos • Evite código duplicado

  34. Formatação

  35. Formatação

  36. Formatação • Crie um padrão ou use padrões já conhecidos

    • Indentação, ponto e virgula, aspas duplas ou aspas simples… • Use ferramentas que te avisam sobre problemas de formatação (ou que corrijam isso para você, prettier estou olhando para você)
  37. Comentários • Comentários mentem, código não! • Comente o necessário

    • Não insira comentários num código ruim, reescreva-o
  38. E muito mais…

  39. Dicas de leitura • Clean Code (Código limpo) • Clean

    Architecture (Arquitetura limpa) • Design Patterns (Padrões de projeto) • Refactoring (Refatoração)
  40. Obrigado. @rogeralbinoi (Twitter, GitHub, Speaker Deck…)