Nos últimos tempos, tenho refletido sobre um conceito que está se tornando cada vez mais necessário no desenvolvimento de software: a simplicidade arquitetural. Especialmente no universo do Flutter, muitos de nós, desenvolvedores, estamos percebendo que projetos extremamente complexos nem sempre resultam em softwares melhores. Na verdade, estamos começando a propor que o legalismo em torno de arquiteturas excessivamente complexas seja reconsiderado.

Durante muito tempo, nos acostumamos a seguir à risca padrões e camadas intermináveis de abstração, acreditando que essa era a chave para um código de qualidade. Mas, na prática, muitos de nós têm observado que, em vez de agregar valor, essas camadas acabam por aumentar a complexidade do código de forma desnecessária. O que estamos propondo agora é uma quebra desse paradigma, onde a arquitetura de software não precisa ser um fim em si mesma, mas sim um meio para alcançar o objetivo de entregar valor de forma eficiente.

Essa reflexão me levou a repensar o caminho que, muitas vezes, seguimos no desenvolvimento. Ao longo dos anos, notei que uma grande parte dos testes que escrevemos não tem um propósito claro além de inflar métricas. Buscamos aquele número mágico de 90% de cobertura de testes, mas será que isso realmente torna o software melhor? A resposta, que muitos hesitam em aceitar, é: nem sempre. Na verdade, mais camadas e padrões podem aumentar a complexidade de forma desnecessária, tornando o código difícil de manter e até mesmo de entender.

Aqui, vale fazer uma pausa para esclarecer algo importante: não sou contra a Clean Architecture, e muito menos contra os testes automatizados. Pelo contrário, sou um grande entusiasta dessas práticas. No entanto, é preciso entender quando e por que aplicá-las. Implementar padrões e escrever testes deve ter um objetivo claro: melhorar a qualidade do software e facilitar sua manutenção. Se isso não está acontecendo, então estamos apenas seguindo modismos ou "boas práticas" sem um entendimento profundo do porquê.

A simplicidade não é sinônimo de negligência. Pelo contrário, pode ser uma escolha consciente de focar no que realmente importa. Muitas vezes, desenvolvemos soluções pensando em todas as situações possíveis, criando camadas e camadas de abstração, mas esquecemos que a complexidade desnecessária também gera problemas. O que estou propondo é um equilíbrio: fazer o necessário, da forma mais simples possível, bem feito. Um código simples e direto, que foca no que realmente agrega valor ao usuário e ao projeto, não é sinônimo de um código pobre.

No contexto de frontend, como é o caso do Flutter, a simplicidade se torna ainda mais relevante. A UI (interface do usuário) é o núcleo de qualquer aplicativo visual, e nosso foco deve estar na criação de experiências agradáveis e funcionais. Ao longo de minha jornada recente, percebi que, ao testar diferentes abordagens reativas — como o uso do State Pattern e de bibliotecas populares de gerenciamento de estado (se você é desenvolvedor Flutter, já deve ter pensado em pelo menos três pacotes; eu testei a maioria) —, consegui criar soluções eficientes e de fácil manutenção, sem sacrificar a qualidade. Esse processo resultou em um código mais limpo e enxuto, mantendo, ao mesmo tempo, a robustez necessária para garantir a escalabilidade do software.

Ao explorar a MiniCore Arch, encontrei uma forma de estruturar meu código que me permitiu reduzir drasticamente o tempo de desenvolvimento. A proposta de ter o estado como parte central da aplicação se mostrou extremamente eficiente, tanto no desenvolvimento quanto na manutenção. Em projetos anteriores, eu costumava seguir à risca os conceitos Clean Architecture aplicados pela proposta Clean Dart, com suas camadas bem definidas e rigorosas. E, embora essa abordagem tenha seu valor, comecei a perceber que nem sempre ela é necessária, principalmente em projetos onde o foco é a entrega rápida de valor ao usuário.

A MiniCore Arch me ensinou que, em muitos casos, podemos adotar uma abordagem mais leve, sem comprometer a organização e a manutenibilidade do código. O resultado é um código funcional, claro e com camadas suficientes para garantir a separação de responsabilidades, mas sem exageros. Por exemplo, ao simplificar a forma como gerencio o estado da aplicação, consigo manter um controle preciso sobre os fluxos de dados sem precisar recorrer a múltiplas camadas de abstração, o que facilita tanto o desenvolvimento quanto o entendimento futuro do código.

Ainda mais importante é o fato de que a simplicidade impacta diretamente a produtividade. Durante o desenvolvimento de um projeto pessoal, percebi que ao reduzir a quantidade de padrões e camadas, consegui entregar mais funcionalidades em menos tempo, mantendo a qualidade do código. E aqui está o ponto principal: simplicidade não é sobre cortar etapas ou ser preguiçoso, é sobre eficiência e foco.

Um exemplo que gosto de dar é o processo de implementação de testes. Em vez de testar exaustivamente cada pequeno método, como fazemos ao tentar atingir altas coberturas de testes, foquei em testar o essencial: as funcionalidades críticas e os fluxos de dados importantes. O resultado? Um código bem testado, porém sem o fardo de manter uma infinidade de testes que, na prática, não agregariam tanto valor assim.

Isso me leva à reflexão que quero compartilhar com a comunidade de desenvolvedores: precisamos questionar quando a complexidade é realmente necessária e quando estamos complicando o que deveria ser simples. Simplicidade não significa renunciar a boas práticas ou deixar de lado a qualidade, mas sim aplicá-las com parcimônia e com um objetivo claro. O desafio está em encontrar o equilíbrio, e acredito que a MiniCore Arch é um exemplo de como podemos fazer isso no desenvolvimento com Flutter.

Por fim, se você é desenvolvedor e está se sentindo preso a arquiteturas complexas, sugiro que experimente uma abordagem mais leve. Teste, faça ajustes e veja como ela pode facilitar o seu processo de desenvolvimento. Afinal, todos buscamos criar códigos simples, de qualidade e que entreguem valor real. Lembre-se: Clean Architecture são apenas diretrizes de como melhorar seu código, não uma regra a ser seguida à risca. Não existe uma receita pronta, e cada projeto merece uma arquitetura pensada individualmente. Você pode se inspirar nas diversas propostas arquiteturais que existem e adaptá-las conforme suas necessidades. Teste diferentes conceitos, converse com seu time e juntos encontrem a melhor solução para o seu contexto.

Para quem quiser conferir um exemplo prático dessa abordagem mais enxuta que mencionei, você pode acessar o código no GitHub através do link: https://github.com/OrlandoEduardo101/tractian_assets. Além disso, recomendo visitar o repositório da Flutterando, que traz uma série de insights sobre como simplificar a arquitetura no Flutter. O repositório pode ser encontrado em: https://github.com/Flutterando/minicore.

Vamos simplificar e focar no que realmente importa. Afinal, a verdadeira arte do desenvolvimento está em criar soluções simples para problemas complexos. E essa simplicidade é o que torna um código verdadeiramente bom.

As informações contidas neste artigo não refletem a opinião do Jornal Folha de Pernambuco e são de inteira responsabilidade de seus criadores. 

Veja também