Cuide bem do seu front-end: boas práticas para um código saudável

Código mal escrito dificulta a compreensão, atrasa a implementação de novas funcionalidades e aumenta os custos de manutenção. Aplicações front-end são tão complexas quanto quaisquer outras e precisam de cuidados equivalentes, aplicando conceitos como Clean Code, SOLID e padrões de arquitetura para garantir qualidade e sustentabilidade no desenvolvimento.

Transcript

2. Cuide bem do seu front-end: boas práticas para um código saudável
3. +10 anos como Desenvolvedora Graduada em Jogos Digitais Sênior Software Engineer na Creditas Esposa do Valter e Mãe do Joaquim Gosto de cozinhar e quero aprender a andar de patins sou a Tais Prazer, @taisreis67
4. Código saudável? Porque devo ter um
5. Código mal escrito dificulta o entendimento, torna a adição de novas funcionalidades e a manutenção mais difíceis, e aumenta o tempo e custo para corrigir problemas e implementar melhorias.
7. Aplicação front-end =
8. Uma aplicação front-end é uma aplicação como qualquer outra. Seu código precisa ser bem cuidado, assim como acontece em outras aplicações. Os problemas de um código mal escrito são os mesmos que temos em qualquer outra aplicação.
9. Nossa Agenda Clean Code Testes e TDD SOLID Ports and Adapters Clean Architecture e DDD
10. Nossa Aplicação Exemplo no Github
11. Clean Code Aplicando no front-end o
12. Clean Code é um conjunto de boas práticas para escrever códigos simples, claros, fáceis de entender, de manter e de testar.
13. Legibilidade Priorize nomes de variáveis, funções, componentes, classes e métodos que sejam claros e descritivos, tornando o entendimento do código fácil para quem vai precisar ler. Nomes de variáveis que sugerem o que ela guarda Nomes de componentes que sugerem sua finalidade Nome de ids e classes de CSS que sugerem o que estilizam Encapsule lógicas em funções com nomes descritos Crie variáveis e constantes com nomes descritivos para armazenar valores do seu código sem deixa-los soltos
14. Simplicidade Adote o princípio KISS (Keep It Simple, Stupid). Evite complexidade excessiva e procure sempre pela solução mais simples e direta para cada problema.
15. Modularidade Divida o código em funções, módulos ou componentes pequenos e coesos, cada um com uma única responsabilidade.
16. Exemplo de Clean Code código no Github
17. Testes e TDD Testando sua aplicação frontend
18. Testar é a garantia de que o que construímos funciona de verdade, protege o usuário e torna nossa aplicação confiável e sustentável.
19. TDD (Test-Driven Development) é uma prática de desenvolvimento onde se escreve um teste que falha antes do código, depois se implementa o código para passar no teste e, por fim, refatora para melhorar a qualidade.
20. Já pensou em TDD utilizando a IA?
21. SOLID Bora aplicar no front-end o
22. SOLID (acrônimo) é um conjunto de princípios que nos ajudam a organizar como nossas funções, compoenentes e estruturas de dados interagem, garantindo códigos mais modulares, flexíveis e fáceis de entender.
23. Single Responsibility Principle Um componente deve ter uma, e apenas uma razão para mudar.
24. Exemplo Se você possuí um componente que pode ser alterado por duas unidades de negócio diferentes, uma alteração feita por um dos lados pode criar bug na outra (mais que uma razão para mudar). Evite compartilhar códigos que parecem iguais mas, tem atores diferentes.
25. Exemplo de Single Responsibility código no Github
26. Open-Closed Principle Um componente deve estar aberto para extensão, mas fechado para modificação.
27. Exemplo Você pode criar um componente base que pode ser reutilizado por outros componentes diferentes extendendo a funcionalidade desse componente base através de parâmetros sem a necessidade de alterar o componente base.
28. Exemplo de Open-Closed Principle código no Github
29. Liskov Substitution Principle Subcomponentes devem poder substituir seus componentes principais sem mudar o comportamento ou quebrar o programa.
30. Exemplo Quando criarmos um componente Button Base para centralizar as lógicas comuns entre os botão que serão utilizados na aplicação e outros botões estendem esse botão, sendo que, um pode substituir o outro porque ambos recebem as mesmas propriedades estamos usando Liskov.
31. Exemplo de Liskov Substitution Principle código no Github
32. Interface Segregation Principle Os componentes, modulos ou classes não devem depender de interfaces com mais informações ou métodos do que eles realmente precisam.
33. Exemplo de Interface Segregation Principle código no Github
34. Dependency Inversion Principle Componentes de alto nível não devem depender de componentes de baixo nível, ambos devem depender de abstrações.
35. Exemplo Quando fazemos os componentes em que seus parâmetros dependem de abstrações (interfaces e tipos) podemos passar qualquer parâmetro para esse componente desde que respeite essa abstração. Dessa forma não precisamos alterar o código do componente e tornamos ele mais reutilizável.
36. Exemplo de Dependency Inversion Principle código no Github
37. Ports and Adapters, Clean Arch e DDD Seu fron-end mais poderoso com
38. Quando sua aplicação front-end se torna muito grande e começa a incluir lógicas de negócio, chega o momento de aplicarmos padrões de arquitetura.
39. Ports and Andapter A arquitetura hexagonal organiza o sistema em um núcleo central com a lógica de negócio isolada, que se comunica com o mundo externo através de portas (interfaces) e adaptadores, permitindo um código desacoplado, flexível e fácil de testar.
40. fonte: artigo Everything You Need to Know About Hexagonal Architecture: Kernel, Ports, Adapters
41. Clean Architecture A Clean Architecture organiza o software em camadas, onde a lógica de negócio fica protegida no núcleo, e as camadas externas cuidam de detalhes como interface e banco de dados, garantindo que as dependências sempre apontem para o núcleo, facilitando manutenção e evolução do sistema.
42. fonte: artigo The Clean Architecture
43. Domain Drive Design Domain-Driven Design (DDD) é uma abordagem que organiza o código para refletir as regras e conceitos do negócio, usando modelos, entidades e serviços que representam claramente o domínio, facilitando o alinhamento entre desenvolvedores e especialistas.
44. fonte: artigo Domain Driven Design: o que é DDD, 3 princípios e como usar?
45. Exemplo de Com aplicar esses padrões de arquitetura código no Github
46. Referências e para saber mais Livro Clean Code Livro Clean Architecture Artigo Sobre Clean Arch, Ports and Adapters e DDD SOLID no front-end Livro Domain Drive Design Código Pokemon Github
47. Obrigada! Qualquer dúvida pode me procurar nas redes sociais @taisreis67