Este é um artigo que quero escrever há muito tempo mas só enrolo... Hoje acordei às 5h e, por alguma força oculta da natureza, sentei em frente ao PC para poder escrever algo misterioso que sai da minha cabeça.

Sem mais enrolação, o objetivo aqui é descrever algumas arquiteturas Front-end que é um tema complexo e estranhamente abordado.

Neste artigo vou abordar um exemplo de arquitetura e armadilhas por não seguir um padrão bem definido. O que trago é uma visão do desenvolvedor de software e coisas que ele deve se preocupar para mitigar problemas futuros, para ele e para a empresa.

Arquitetura de software é sobre o que é importante para o negócio.

Evolução de carreira é um tema muito importante — e, muitas vezes, pode ser desafiador traçar os caminhos certos ou escolher os temas ideais para estudar.

Pensando nisso, compartilho aqui alguns tópicos essenciais para quem deseja ingressar ou se aprofundar no desenvolvimento Front-end.

Design de aplicações é um tema extremamente importante para o desenvolvimento de software. Vejo muitas pessoas não tendo ideia de como criar uma boa arquitetura, podendo criar grandes complicações à medida que o sistema vai evoluindo, novas features, novas demandas, problemas, pressão por entrega e muitos outros fatores que contribuem para o aumento da complexidade da aplicação.

Sistemas inteiros podem ser refeitos pelo simples fato do time não ter criado uma boa arquitetura, ao menos um início ideal que possibilite evolução e adaptação do projeto. Isso pode ocorrer por diversos fatores, falta de conhecimento e pressão para realizar a entrega (muito comum), este último cria uma armadilha por achar que pular etapas do software visando somente velocidade e entrega não vai afetar a qualidade e escala.

Neste artigo vou abordar alguns problemas que podem ocorrer por não seguir um padrão bem definido. O meu objetivo é trazer a visão do desenvolvedor de software e coisas que ele deve se preocupar para mitigar problemas futuros, para ele e para a empresa.

Uma coisa bem simples, mas que pode virar um grande problema para projetos Web é a organização de ícones.

É extremamente comum o uso de bibliotecas como HugeIcons, Lucide, Material Icons, Font Awesome, React Icons e muitas outras e bem natural que o time/pessoa responsável pelo design crie os próprios ícones, de acordo com a necessidade do projeto e da equipe.

Essa escala e mistura de ícones pode acarretar despadronização do projeto, muitas bibliotecas exportam ícones parecidos e com uma infinidade de características.

Uma forma que gosto de fazer para evitar este problema é padronizar os ícones em um único arquivo, exportando somente os possíveis no projeto.

Uma das coisas mais difíceis em um projeto Node é manter as bibliotecas atualizadas. Quem trabalha com gerenciamento de pacotes utilizando Node sabe bem do que estou falando. Em produção, um projeto pode facilmente escalar suas bibliotecas — e, consequentemente, as subdependências que vêm junto — tornando a tarefa de manter tudo isso atualizado bastante desafiadora.

Manter uma code base atualizada pode se tornar difícil à medida que o projeto cresce e novas funcionalidades e bibliotecas vão sendo adicionadas.

Durante todo o projeto, atualizações minor e patch são muito comuns nas bibliotecas e, na maioria dos casos, não causam transtornos e até mesmo são transparentes para o time de desenvolvimento.