Executando verificação de segurança...
4
jarbas
3 min de leitura ·

O olhar de um front-end sobre Projetos React, Angular e Design Patterns.

Incômodo

Depois de alguns anos desenvolvendo todo tipo de aplicação front-end, eu senti que estava faltando algo. Todo começo de projeto é a mesma coisa, roda um comando, configura uma coisa ou outra e pronto, pode codar. Porém, eu comecei a sentir falta de uma estrutura ali, parecia que os meus projetos estavam todos bagunçados.

No início todo projeto é lindo e bem estruturado, mas com o passar do tempo, parece que tudo se transformava numa grande bola de neve. Adicionar novas features, manutenção do código, debugar um arquivo de +500 linhas, testes... e uma coisa que poderia ser simples, acabou se tornando uma dor de cabeça. E aí foi quando eu comecei a procurar e me aprofundar melhor sobre a escalabilidade das coisas e junto disso, design pattern.

No React, se você não tem uma boa base de programação, fluxograma e regras de negócios, você pode acabar fazendo uma bomba relógio. Eu nunca tive Tech Leader ou um fluxograma de projeto para me orientar em algumas coisas, então eu iniciava e desenvolvia os projetos do jeito que achava correto ou no mínimo, funcional. E de repente, boom!, virou uma bomba relógio. Código em todos os lugares e de qualquer jeito. O importante é entregar a task. (Só que não).

Quando isso começou a me incomodar, fui atrás de estudar arquitetura de projetos, design pattern e me deparei com Angular:

Angular

Em um artigo desses qualquer, lembro que li um que explicava sobre MVC e como o Angular aplica isso. Eu fiquei muito curioso em saber como um framework aplica um design pattern e então comecei a estudá-lo.

Com algumas horas de estudo você já percebe a diferença do Angular para o React. Eu tive uma chave virada na minha cabeça depois de desenvolver uma simples to-do-list em Angular para pegar a sintaxe. A estrutura do projeto, serviços, injeção de dependência, construção de rotas, formulários, requisições http e mais tantas outras coisas que ainda estou estudando. O Angular disponibiliza tudo isso e de uma forma muito objetiva.

Aprender Angular e aprender React são duas coisas diferentes, mas iguais. Angular tem uma curva de aprendizado maior, por conta da abordagem estruturada. No React a curva de aprendizado é menor, com uma abordagem voltada para componentes, fica mais rápido o aprendizado.

O Angular já oferece uma arquitetura de projeto pra você, isso deixa seu código mais organizado e simplifica a manutencão de projetos de grande escala. O React não oferece isso, é uma lib com arquitetura em componentes e flexível e aí que mora o perigo. NÃO ESTOU DIZENDO QUE NÃO DÁ PARA MANTER UMA ARQUITETURA COM REACT, dá pra manter, mas exige um conhecimento bem mais sólido da área.

Mas não se preocupe, uma base sólida em Javascript é a chave pra entender essas coisas.

A verdade é que eu estou muito maravilhado com o Angular e espero poder trabalhar com ele em algum momento.

E não esqueça de estudar design pattern, uma hora ou outra ele vai servir pra você.

Carregando publicação patrocinada...
2
wbartz

Concordo em partes com o que você diz. O Angular é realmente bem interessante, o fato dele te forçar um padrão é bom até certo ponto, quando você tem uma equipe mas junior e precisa que todos sigam o mesmo padrão, ele é ótimo, mas quando se precisar fugir muito do "jeito" Angular de se fazer, ele acaba exigindo muita customização e muito conhecimento do framework.
Quanto ao React, ele oferece bastante liberdade para se definir os padrões, o que costumo fazer é antes de iniciar um novo projeto, eu reuno a equipe e definimos os padrões que vamos seguir, e após isso, vamos cobrando nos PR's. Mas você pode usar algumas libs pra automatizar isso, como por exempo o Conventional Commits, e o próprio eslint, onde você pode forçar algumas questões de código.

1
jarbas
Autor
Autor

Ponto muito interessante. Em que momento você acha que vai ter que fugir muito do "jeito" Angular de se fazer código? Tem algum exemplo que possa compartilhar?

1
wbartz

No meu caso, participei de um projeto que precisavamos alterar a ordem de carregamento dos arquivos, e não lembro exatamente por que, mas precisamos alterar um pouco a estrutura de arquivos, na época era um projeto para um banco, que tinha uns requisitos bem diferentes do usual, pode ser que você nunca precise fugir do "jeito" Angular de ser. Talvez isso já não aconteça mais no Angular 17, eu trabalhei muito com AngularJS e até o Angular 13.

2
CarlosH

Eu também estava na mesma que tu, trampava por conta própria e tal, tinha ajuda nas regras de negocio e só, mas a arquitetura, e como eu ia fazer ficava por minha conta. Acabei criando uma bomba relogio no primeiro projeto, mas acabou que me desenvolvi muito a partir daí, acabei procurando melhorias que poderia aplicar nos meus códigos, uma das coisas que mais agregou foram os design patterns e o SOLID, indiretamente eu aplicava quando para pra pensar "como posso melhorar isso e facilitar minha vida?", sempre começava as funções aplicando o conceito de responsabilidade unica, e agora já tenho mais noções de padrões de código e um pouco de arquitetura, ainda não crio projetos como queria, mas estão com uma ótima qualidade o código, e facilita a escalabilidade e manutenção. Sobre o Angular acho um excelente framework, escala bem por ser bem opnativo, acho uma ferramenta poderosa, embora nunca tenha usado em produção.

1
jarbas
Autor
Autor

Infelizmente, eu acredito que muita empresa ainda age dessa forma. Invés de ter um time conciso e eficiente,regras de negócio clara, fluxograma, etc, contratam um junior e botam ele pra fazer projetos com 3 meses de experiência e aí depois não se sabe o por que do projeto não ter escalado bem.