Utilizando Clean Code para deixar seu código ainda mais manutenível - TDC Transformation - Grupo Boticário

Nesta palestra explicarei o que é Clean Code, a sua importância e algumas dicas práticas de como escrever um código melhor.

Roger Albino - TDC Transformation 2021 - Grupo Boticário - GBTech - 25 de agosto de 2021

Transcript

1. Roger Albino - @rogeralbinoi Utilizando Clean Code para deixar o seu código ainda mais manutenível 25 de agosto 2021
2. Roger Albino - Desenvolvedor Front-end há 8 anos - Developer Specialist no Grupo Boticário - Mentor no Programa Desenvolve GB - React, React Native, Serverless e NextJS @rogeralbinoi / @rogeralbino - 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. Que tal reinventar o futuro da Beleza com a gente? Acesse grupoboticario.gupy.io/ e conheça as oportunidades!
5. Código limpo (Clean Code) Livro por Robert C.Martin (Uncle Bob) Imagem retirada de: https:/ /www.amazon.com.br/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM • Livro com ensinamentos para escrever código de qualidade.
6. Se você está começando Não se assuste! • Eu já escrevi código ruim • Você vai escrever muito código ruim ainda… • Tá tudo bem! • Faz parte do aprendizado
7. O que é um código bom?
8. A única mensuração válida para qualidade de código: WTFs / minute(mas que diabos / minuto)
9. Saber o que é um código bom, não te faz escrever 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á não tá bom?
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. Um código ruim reduz a produtividade do time com o passar do tempo Produtividade / Tempo decorrido do projeto Produtividade 0 25 50 75 100 Tempo decorrido do projeto Abril Maio Junho Julho Agosto
13. Na real você tá queimando dinheiro..
14. Vamos para algumas dicas?
15. Nomes • 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
16. Dar nomes é bem difícil mesmo
17. Nomes
18. • Use nomes que revelem o seu propósito Nomes
19. • Use nomes que revelem o seu propósito • Evite dicas erradas Nomes
20. Nomes • Use nomes que revelem o seu propósito • Evite dicas erradas
21. Nomes • Use nomes que revelem o seu propósito • Evite dicas erradas • Evite números mágicos
22. 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)
23. 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)
24. Nomes • Evite contexto desnecessário
25. Nomes • Evite contexto desnecessário • Crie nomes buscáveis e pronunciáveis
26. Funções / Métodos
27. Funções / Métodos • Devem ter apenas uma responsábilidade (Fazer apenas uma coisa)
28. 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)
29. Funções / Métodos • Blocos de identação (if, else, while), devem ter apenas uma linha (possivelmente chamando outra função)
30. 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)
31. Funções / Métodos • Evite listas grandes de parâmetros (mais que dois já é muito)
32. Funções / Métodos • Evite listas grandes de parâmetros (mais que dois já é muito)
33. Funções / Métodos • Evite código duplicado
34. Funções / Métodos • Evite código duplicado
35. Formatação
36. Formatação
37. Formatação
38. 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ê,)
39. Testes, testes, testes… • Se um código está difícil de ser testado, provavelmente tem algum problema no design dele • Bons testes te ajudam a garantir que tudo está funcionando direitinho • Escrevi código novo, ele deve estar coberto por testes • Corrigi um BUG, mais testes devem ser adicionados
40. Comentários • Comentários mentem, código não! • Comente o necessário • Não insira comentários num código ruim, reescreva-o
41. Alguns princípios • DRY (Don’t repeat yourself ) - evite código duplicado • KISS (Keep it Simple stupid) - Complexidade demais atrapalha • SOLID - (Príncipios do Design Orientado a Objetos)
42. Algumas ferramentas
47. •E muito mais…
48. Dicas de leitura • Clean Code (Código limpo) • Clean Architecture (Arquitetura limpa) • Design Patterns (Padrões de projeto) • Refactoring (Refatoração)
49. Obrigado. Acesse grupoboticario.gupy.io/ e conheça as oportunidades!