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.

Transcript

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

   View Slide

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…
   

   View Slide

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.
   

   View Slide

4. Acesse grupoboticario.gupy.io/ e conheça as oportunidades!
   Que tal reinventar o futuro da beleza com a gente?
   

   View Slide

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
   

   View Slide

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!
   

   View Slide

7. O que é um código bom?
   

   View Slide

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.
   

   View Slide

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/
   

   View Slide

10. Um Código bom realmente importa?
    Se tá funcionando já tá bom não tá?
    

    View Slide

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
    

    View Slide

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.
    

    View Slide

13. Na real você tá queimando dinheiro!
    

    View Slide

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
    

    View Slide

15. Dar nomes é muito difícil
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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)
    

    View Slide

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)
    

    View Slide

22. Nomes
    • Evite contexto desnecessário
    

    View Slide

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

    View Slide

24. Nomes
    • Evite contexto desnecessário
    
    
    • Evite números mágicos
    
    
    • Crie nomes buscáveis e pronunciáveis
    

    View Slide

25. Classes
    • Nome de classes: Substantivos
    (Account, Cart, Shipping)
    
    
    • Nome de Métodos: Verbos (addItem,
    removeItem, getProductList)
    

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

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)
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

34. Formatação
    

    View Slide

35. Formatação
    

    View Slide

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ê)
    

    View Slide

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
    

    View Slide

38. E muito mais…
    

    View Slide

39. Dicas de leitura
    • Clean Code (Código limpo)
    
    
    • Clean Architecture (Arquitetura limpa)
    
    
    • Design Patterns (Padrões de projeto)
    
    
    • Refactoring (Refatoração)
    

    View Slide

40. Obrigado.
    @rogeralbinoi (Twitter, GitHub, Speaker Deck…)
    

    View Slide