Uma experiência com arquitetura e princípios SOLID no front-end

Olá amigos!

Contarei uma experiência que tive com arquitetura e princípios SOLID no front-end.

Começo
No final do ano passado 2022, me deparei com um novo projeto que poderia ou não assumir a frente. Poderia tratá-lo como mais um projeto vindo para a nossa carteira de clientes, mas, dessa vez pedi para tomar a frente e sair da zona de conforto aprendendo mais, não só em relação ao código, mas também em como decidir os padrões para uma aplicação e dar início a um projeto do zero.

Realizando as pesquisas
Aprendi muitas coisas, mas o que venho compartilhar hoje é sobre arquitetura e como poderia aplicar o SOLID (não entrarei na explicação teórica de SOLID e arquitetura nesse momento) nessa parte do front-end. Tive algumas dificuldades em saber como fazer isso. A experiência que tive para pesquisar materiais sobre esses assuntos para front-end não se compara com a do back-end, existem muito mais exemplos e documentações detalhada. Encontrei algumas boas ideias, mas nada que me agradasse.

Mão na massa
Fiz um apanhado do que já sabia sobre SOLID e arquitetura, revisitei alguns projetos bem organizados que tive contato e coloquei a mão na massa.

Apesar de ficar na zona de conforto (mas sempre aprendendo algo novo) com JavaScript, TypeScript e React, a parte de arquitetura e SOLID foi um desafio à parte.

Explicando um pouco do que fiz nesse projeto, podemos ver na imagem que coloquei acima. Temos duas principais pastas responsáveis pela camada de "view", "components" e "pages". Olhando bem fica muito intuitivo, "pages" onde ficaram minhas páginas e "components" são meus componentes genéricos, responsáveis por códigos que só acontecem nele, que não precisa ser externalizado.

Seguindo os princípios do SOLID S — Single Responsiblity Principle (Princípio da responsabilidade única). A decisão de criar componentes dentro dos fluxos de páginas, foi feita devido a existência dos mesmos se repetirem várias vezes e não aparecerem em outras páginas. Mas também são componentes que exigem uma responsabilidade maior, como um formulário ou uma listagem, que por exemplo aparecem muita das vezes uma única vez dentro de um fluxo específico. Assim, o "pai" "index.tsx" fica somente com a responsabilidade de chamar o formulário ou a listagem.

Com essa estratégia consegui uma abordagem bem interessante, e comecei a recomendar aos meus parceiros de equipe a seguerem o fluxo de desenvolvimento das tasks começando a codar nas "services", "contexts", "hooks" e partir para "view". E interfaces quando precisar, então pode surgir a necessidade de criar interfaces globais na parte de service, context ou view. Assim, tasks que demoravamos 3 dias para realizar, com a organização nosso time reduziu para 1 dia e meio no máximo. A nossa produtividade aumentou e conseguimos entregar tudo dentro do prazo com a qualidade do nosso acordo técnico (assunto para outra hora), algo que tinhamos medo de não acontecer, pois todo nosso time é composto por desenvolvedores juniors.

Segue à imagem para representar como ficou a organização, dando um zoom out da "src", que nessa imagem chamei de view.

Conclusão
É isso amigos, sempre busque organizar os projetos de vocês, para aumentar a facilidade da manutenção do código e integração de novas features. Devido ao investimento de tempo inicial na parte de planejamento e organização, isso pode fazer toda a diferença.

Obrigado pela atenção e até a próxima.