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.
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…)