Bazuca para matar mosquitos  

      

      

Hoje, com a ascensão das IAs generativas, é inegável o aumento da produtividade dos desenvolvedores. Eu sou um dev que, para necessidades pontuais, pede código, sim. Hoje mesmo, pedi para o ChatGPT ajustar um método builder porque havíamos mudado alguns contratos. Em questão de segundos, aquele código estava pronto para mim, mas eu sabia o que estava fazendo e também o motivo dessa mudança de contrato para a arquitetura como um todo. Esse é o verdadeiro diferencial da produtividade: não perdemos mais tanto tempo com pequenos detalhes.

   

   

Onde quero chegar com essa introdução? Eu estudei design patterns, estudei arquiteturas de software, já li os livros do Uncle Bob, sei que, se você misturar SOLID + Clean Code + Arquitetura Hexagonal e um pouco de DDD, você tem Arquitetura Limpa. Sei aplicar um monólito com facades bem definidas, onde pode-se escalar para microsserviços… mas para quê escalar para microsserviços? Para quê Clean Code à risca, como se você estivesse executando um ritual? Tudo tem um motivo e um porquê, e a graça está justamente em descobrir por conta própria que fez um overengineering. Aí você pulou mais uma etapa como dev.

   

Bem, vejo muita gente no LinkedIn mencionando que isso tudo virou modismo… Sim, virou, mas que bom. Eu, particularmente, acho ótimo um projeto bem estruturado, com suas camadas bem definidas, interfaces claras, domínios e objetos de valor bem identificados. Mas um dia você foi contratado para fazer um pequeno ERP para uma padaria, onde há poucos casos de uso e você precisa desse pagamento rápido. Você vai aplicar Arquitetura Limpa para um software com uma ou duas integrações e uns seis casos de uso? Eu não escolheria… Então você resolveu aplicar Arquitetura Limpa, e o que você poderia entregar em semanas com um MVC bem estruturadinho ou até uma Layered Architecture, levou o dobro de tempo. Bazuca para matar mosquito.

   

Mas onde eu entraria com Arquitetura Limpa? Regras de negócio complexas e imutáveis, necessidade de separação entre camadas (domínio, aplicação, infraestrutura), permitindo assim testar regras de negócio sem precisar de um banco de dados real ou dependências externas, porque a intenção é escalar aos poucos, com qualidade. Você pensa no problema sem pensar no framework. Mas a padaria não merece essa qualidade? Se ela, como negócio, tiver a intenção de se tornar uma panificadora com abrangência nacional, filas de pedidos, gestão de inúmeros fornecedores, formando assim até dezenas de entidades, sim. Mas só se for isso; se não, o MVC, que muita gente emocionada acha simplista, já atende.

   

Tá, mas e o Clean Code? SOLID? O projeto é para ser produtivo e tem colegas ajudando? Eu vejo ambos como empatia: você está escrevendo código para que outros entendam, com ótimas referências do que é bacana fazer com suas classes. Mas vá com calma nas interfaces. O conceito de Locality of Behavior já atende, não será necessário navegar por meia dúzia de pastas.

   

No fim das contas, tudo se resume a contexto e bom senso. Arquitetura, padrões e boas práticas existem para ajudar, não para engessar o desenvolvimento. Seguir um modelo rigorosamente sem considerar as necessidades do projeto pode ser tão prejudicial quanto ignorar princípios básicos de organização. Não adianta aplicar SOLID, Clean Code e Arquitetura Limpa em qualquer situação se isso apenas tornar o processo mais burocrático e demorado sem um benefício real. Ao mesmo tempo, negligenciar estrutura e clareza pode comprometer a escalabilidade e a manutenção do sistema no futuro.

      

Cada decisão tem um custo, e o equilíbrio está em entender quando a complexidade é justificada e quando uma solução mais simples já resolve o problema. No final, código bem escrito é aquele que entrega valor de forma eficiente, sem exageros e sem romantização.