Resumo Executivo

Rafael Corradini da Cunha; Vanessa Matias Leite

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

As interfaces oferecidas aos usuários tornam-se cada vez mais complexas à medida que grandes organizações entregam soluções que unem múltiplas funcionalidades em um único ecossistema, como superapps, marketplaces e redes sociais integradas. Com esse aumento exponencial de complexidade, o desenvolvimento de software exige uma visão de longo prazo para que a base de código evolua de forma saudável, permitindo que decisões técnicas auxiliem na redução de custos de implementação, manutenção e testes. A necessidade de criar essas interfaces impulsiona o surgimento de diversas tecnologias, entre as quais se destaca o React, uma biblioteca JavaScript voltada para simplificar a forma como elementos visuais e suas interações são implementados no front-end. Entretanto, o uso isolado de qualquer tecnologia, incluindo o React, não garante por si só a escalabilidade da aplicação, exigindo que o planejamento se concentre principalmente na arquitetura e na organização dos componentes como um todo (Martin, 2019).

Uma arquitetura de software de alta qualidade é avaliada não apenas pela capacidade de fazer o sistema funcionar, mas primordialmente pela habilidade em minimizar o esforço humano necessário para construir e manter o sistema ao longo de seu ciclo de vida. O objetivo final reside na redução de custos operacionais e na maximização da produtividade da equipe de desenvolvimento, resultando em um sistema fácil de entender, desenvolver e implantar. Uma estrutura bem delineada permite que decisões sobre tecnologias específicas, como bancos de dados e frameworks, sejam adiadas, mantendo o sistema flexível e adaptável a mudanças futuras sem comprometer a integridade do núcleo de negócio (Martin, 2019). Para promover essa evolução saudável, o emprego de padrões arquiteturais consolidados é fundamental, destacando-se a Arquitetura Limpa, que propõe a divisão do software em camadas de modo que as abstrações de alto nível não dependam de detalhes de implementação de baixo nível.

Estudos acadêmicos corroboram que a Arquitetura Limpa melhora significativamente a manutenibilidade e a testabilidade do código, permitindo a realização de testes das regras de negócio independentemente de suas implementações externas, como interfaces gráficas ou serviços de terceiros (Sanchez et al., 2022). A aplicação desse padrão em sistemas de backend demonstra melhorias em todas as métricas de manutenibilidade, conforme evidenciado em análises de bases de código complexas (Nugroho et al., 2022). No contexto de sistemas voltados para o cliente, observa-se um aumento na facilidade de teste e uma simplificação na manutenção, garantindo que o programa possa ser alterado e aprimorado com menor esforço e sem causar falhas em componentes adjacentes (Bukovčan et al., 2021). A Arquitetura Limpa garante que a implementação de uma nova regra em uma política interfira o mínimo possível no que já foi desenvolvido, reduzindo a incidência de falhas a longo prazo, embora demande um custo de desenvolvimento inicial mais elevado (Nugroho et al., 2022).

A metodologia aplicada para validar esses conceitos consistiu em um estudo de caso comparativo fundamentado no desenvolvimento de uma aplicação web utilizando React. A pesquisa estruturou-se em torno de duas implementações distintas de módulos específicos: uma aderente aos princípios da Arquitetura Limpa, denominada csnades-clean, e outra baseada em uma abordagem menos modularizada e sem a separação rigorosa de camadas, denominada csnades-gohorse. O objetivo central foi comparar os níveis de manutenibilidade de cada abordagem por meio de métricas quantitativas de software, utilizando a ferramenta de código aberto code-health-meter para a extração de dados precisos sobre a saúde do código-fonte.

As métricas selecionadas para a análise incluíram a Complexidade Ciclomática, que mede o número de caminhos lineares independentes através do código, onde valores menores indicam maior facilidade de manutenção. Também foi utilizada a Contagem de Linhas de Código (SLOC), abrangendo tanto o tamanho físico quanto o lógico, como indicativo de esforço e complexidade. O Índice de Manutenibilidade (IM) foi a métrica composta central, combinando complexidade ciclomática, volume de Halstead e linhas de código para gerar um valor percentual de facilidade de manutenção. Adicionalmente, foram aplicadas as métricas de Halstead, que quantificam o comprimento do programa, o volume, o nível de dificuldade, o esforço de implementação e o tempo estimado para entender ou implementar o código, baseando-se no número de operadores e operandos únicos e totais.

A estrutura da implementação csnades-clean foi organizada em quatro camadas principais com fluxo de dependência unidirecional, partindo da interface de usuário em direção ao domínio. A camada de Domínio foi concebida para conter toda a lógica de negócio e as entidades, permanecendo completamente independente de tecnologias externas ou frameworks. Nela, definiram-se interfaces como NadeAdapter, que estabelece contratos para métodos como listNades e rateNade, sem se preocupar com a implementação técnica da comunicação. Essa separação permite que as regras de negócio sejam testadas de forma isolada, protegendo o núcleo do sistema contra mudanças em detalhes externos (Martin, 2019).

A camada de Adaptadores funcionou como uma ponte entre o domínio e as tecnologias externas, implementando as interfaces definidas anteriormente. Sua responsabilidade principal foi a conversão de dados entre formatos convenientes para agências externas e formatos adequados para as camadas internas. No estudo, o adaptador NadeAdapter utilizou a biblioteca Axios para a comunicação com uma API externa, demonstrando o princípio da inversão de dependência, onde os detalhes de implementação dependem das abstrações (Martin, 2019). Caso a tecnologia de comunicação fosse alterada para GraphQL, apenas o adaptador exigiria modificações, sem impacto nas camadas de domínio ou de interface.

A camada de Serviços e Casos de Uso orquestrou o fluxo de dados, contendo as regras de negócio específicas e expondo-as de forma simplificada para a apresentação por meio de hooks do React, como o useNadeList. Esses serviços atuaram como intermediários, tratando a lógica de estado, carregamento e erros com o auxílio da biblioteca React Query. Essa organização manteve a lógica de gerenciamento de estado fora dos componentes visuais, tornando-os mais limpos e focados na renderização. Por fim, a camada de Apresentação foi dividida em componentes puros (visuais), containers (conexão com serviços) e telas (composição de páginas), garantindo que os elementos de interface fossem fáceis de testar e reutilizar (Lakhai, 2024).

Os resultados e discussões basearam-se na análise de três telas com diferentes níveis de complexidade. A primeira tela, NadeList, responsável por listar recursos de uma API externa, revelou discrepâncias significativas entre as duas abordagens. Na versão sem arquitetura definida, o Índice de Manutenibilidade foi de 63,66%, com uma Complexidade Ciclomática de 13 e um total de 107 linhas de código físico. Em contrapartida, a versão com Arquitetura Limpa apresentou um IM superior de 69,45%, reduzindo a Complexidade Ciclomática para cinco e o número de linhas de código para 50. Essa redução drástica de 107 para 50 linhas físicas evidencia como a abstração da comunicação externa torna a renderização do componente mais enxuta e legível.

A análise das métricas de Halstead para a tela NadeList reforçou a superioridade da abordagem estruturada. O esforço de implementação na versão csnades-clean foi de 4002,48 bit, enquanto na versão csnades-gohorse esse valor saltou para 29603,91 bit. O tempo estimado para implementar ou entender o programa foi reduzido de 1644,66 s para apenas 222,36 s na versão limpa. O número estimado de bugs também apresentou queda, saindo de 0,49 para 0,13. Esses dados demonstram que a utilização de camadas de adaptadores e serviços remove a carga cognitiva do componente de apresentação, permitindo que o desenvolvedor foque na lógica visual sem se preocupar com detalhes de infraestrutura.

Na segunda tela analisada, GameMapList, que apresenta uma complexidade intermediária, a tendência de melhoria se manteve. O projeto csnades-clean alcançou um IM de 71,61% contra 67,07% da versão desestruturada. A Complexidade Ciclomática foi mantida em cinco na versão limpa, enquanto atingiu 10 na versão gohorse. O esforço de implementação exigido pela abordagem sem arquitetura foi de 13990,78 bit, aproximadamente 3,8 vezes maior do que os 3637,87 bit registrados na versão com Arquitetura Limpa. O tempo de compreensão também foi significativamente menor, registrando 202,1 s na versão estruturada frente a 777,26 s na versão simplista.

A terceira tela, NadeDetails, introduziu o maior nível de complexidade ao permitir ações do usuário que acionavam múltiplas chamadas de API. Nesta análise, a diferença entre as abordagens tornou-se ainda mais acentuada. O Índice de Manutenibilidade na versão limpa foi de 65,50%, enquanto na versão gohorse caiu para 59,83%. A Complexidade Ciclomática dobrou na versão sem arquitetura, atingindo 20 caminhos independentes, contra 10 na versão estruturada. O esforço de implementação na versão csnades-gohorse atingiu o valor crítico de 85394,11 bit, enquanto a versão csnades-clean exigiu 12603,67 bit. O tempo para entender o código na versão desestruturada foi de 4744,12 s, comparado a apenas 700,2 s na versão limpa, uma redução de quase sete vezes no esforço cognitivo.

A discussão dos resultados indica que, à medida que a funcionalidade se torna mais complexa e exige mais interações com serviços externos, os benefícios da Arquitetura Limpa tornam-se mais evidentes e necessários. A centralização de lógica em componentes de interface, como observado na versão gohorse, resulta em arquivos extensos, com alto acoplamento e difícil rastreabilidade de erros. A implementação que utiliza a arquitetura limpa abstrai a complexidade da comunicação, tratando exceções e conversões de dados em camadas específicas, o que garante que a camada de apresentação permaneça isolada dos detalhes da fonte de dados externa.

Embora a implementação inicial da Arquitetura Limpa demande um investimento de tempo superior devido à criação de interfaces, adaptadores e serviços, esse esforço se traduz em um código mais resiliente a falhas e mais fácil de evoluir. A adoção desse padrão implica um custo inicial de desenvolvimento mais elevado, mas justifica-se pela longevidade e saúde do software (Nugroho et al., 2022). A separação de responsabilidades permite que diferentes desenvolvedores trabalhem em camadas distintas simultaneamente, além de facilitar a escrita de testes unitários para a lógica de negócio sem a necessidade de simular todo o ambiente de interface ou rede (Sanchez et al., 2022).

A flexibilidade proporcionada pela inversão de dependência é um dos pontos mais relevantes na discussão prática. Ao definir contratos claros na camada de domínio, o sistema torna-se agnóstico em relação às ferramentas externas. Se houver necessidade de substituir uma biblioteca de gerenciamento de estado ou um cliente HTTP, as alterações ficam restritas às camadas periféricas, sem contaminar o núcleo da aplicação. Essa característica é essencial para sistemas de grande porte que precisam lidar com a obsolescência tecnológica e a necessidade de atualizações constantes (Bukovčan et al., 2021).

As limitações do estudo residem no fato de ter sido aplicado a um conjunto específico de funcionalidades em uma aplicação React, o que sugere a necessidade de pesquisas futuras para validar esses resultados em outros frameworks como Angular ou Vue.js. Além disso, a investigação poderia ser estendida para o desenvolvimento mobile com React Native ou Flutter, verificando se os ganhos de manutenibilidade se mantêm consistentes em diferentes plataformas e ecossistemas de execução. A complexidade geral da aplicação e o número de domínios envolvidos também são variáveis que podem influenciar a magnitude dos benefícios observados (Lakhai, 2024).

Conclui-se que o objetivo foi atingido, uma vez que a aplicação da Arquitetura Limpa no front-end com React demonstrou de forma quantitativa e qualitativa a produção de um código significativamente mais manutenível, modularizado e desacoplado. As métricas de software evidenciaram uma redução notável na complexidade ciclomática e no esforço necessário para entender e modificar o código, benefícios que se tornam mais expressivos conforme a complexidade das funcionalidades aumenta. Embora exija um investimento inicial maior, a estrutura em camadas garante a longevidade do software e a facilidade de implementação de novas funcionalidades, confirmando que a organização arquitetural é um fator determinante para a escalabilidade e a saúde de sistemas modernos.

Referências Bibliográficas:

Bukovčan, M.; Blažević, D.; Nenadić, K.; Stević M. 2021. Clean Architecture of Client-Side Software Development for Smart Furniture Control. Mediterranean Conference on Embedded Computing (MECO) 10. 1-5.

Lakhai, V., 2024. A Method to Increase Maintainability of Microservice Software Through Enhanced Event Management. International Conference on Computer Science and Information Technologies (CSIT) 19. 1-4.

Martin, R. 2019. Arquitetura Limpa: O Guia do Artesão para Estrutura e Design de Software. 1ed. Starlin Alta Editora e Consultoria Eireli, Rio de Janeiro, RJ, Brasil.

Nugroho, Y.; Kusumo, D.; Alibas, M. 2022. Clean Architecture Implementation Impacts on Maintainability Aspect for Backend System Code Base. International Conference on Information and Communication Technology (ICoICT) 10. 1-6.

Sanchez, D.; Rojas, A.; Florez, H. 2022. Towards a Clean Architecture for Android Apps using Model Transformations. IAENG International Journal of Computer Science (49). 1-10.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy