A modinha do clean architecture
Tags: java
Published: 2023-07-20 18:36:13

A algum tempo eu e um colega participamos como convidado de uma reunião com outros desenvolvedores de uma equipe. 

A missão dessa equipe era projetar e reescrever uma aplicação muito importante para a empresa, eu e meu colega iriamos ser o ponto de apoio para dúvidas sobre a aplicação.

## A reunião

A sensação que tínhamos durante a reunião, era que estávamos no meio do pregão da bolsa de valores. 

Todos apresentando suas ofertas da melhor forma, um atravessa a fala do outro, outro rebate a ideia do outro e alguns permaneciam calados só acompanhando.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dntvpewihkh1gi1bo227.jpeg)

Todos queriam se apresentar como o mais capacitado e o mais técnico para ganhar a competição com sua proposta _(sim, teve competição entre eles)_

Durante a calorosa discussão que estava praticamente em quais frameworks, banco de dados, soluções em nuvem, message broker e linguagem de programação iriam usar _(aliás isso é o que importa não é verdade, depois pensamos no que o negócio precisa)_, era quase que unânime também o tema clean architecture.

E todos se expressavam da forma mais elegante possível, clean architecture, clean arch ou CA _(confesso que confundi com a loja C&A no dia)_. 

Era uma briga de ego enorme, devemos construir usando "clean arch" com uma solução orientada a eventos, com o framework A e banco de dados C e message broker D diziam eles. _(O engraçado é que as soluções eram sugeridas sem ao menos avaliar o objetivo do software, não tinha uma métrica, nada do tipo para justificar usar isso ou aquilo)_

Vencia quem era o melhor nos argumentos técnicos mais bonitos, domínio das tecnologias mais atuais, parecia uma dança de acasalamento, quem dançava melhor ganhava.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/75s6rzpaw1oijg1ct28a.gif)

Então, em meio a isso tudo, uma dev recém promovida para o time de engenharia, que ficou calada o tempo todo, levanta a mão e fala: **_acho que clean architecture não é isso não._**

**"Pasme" Restante do time**
![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/weuc8qfugobb974gg08h.gif)

Aqui surgiu várias respostas ao questionamento da nossa dev

clean architecture é:

- Programar sem framework _**(quase todos afirmaram isso)**_ 
- Programar utilizando contratos de interfaces
- Utilizar DDD
- Utilizar SOLID
- Utilizar hexagonal
- E a mais absurda vinda de alguns "experts" da equipe _**(isso é modinha de mercado)**_

_"Vou falar um pouco sobre os experts mais abaixo"_

## Falando sério
 
Apensar das brincadeiras o assunto é preocupante, esse mesmo relato já presenciei em outras equipes e projetos. 

O grande problema não é só a falta de conhecimento ou experiência para tocar um tema como esse, mas como esses times ficam totalmente autônomos em decisões tão importantes sobre definir uma arquitetura para um software, linguagem de programação, framework, banco de dados, etc.

Equipes auto gerenciáveis e autônomas é excelente, mas qual o preço disso para equipes que não tem a capacidade de ser totalmente autônomas? Alguém está vendo isso?

## Clean architecture não é isso

Não é programar sem framework, isso surpreende muito, a falta de ler o tema um pouco mais a fundo, deixar o ego de lado.

De uma forma básica, clean architecture é um conjunto de boas práticas e abordagens que você deve levar em consideração para deixar seu software, os fontes de seu software limpo de fatores que não fazem parte do seu objetivo, que é a regra de negócio feita para ele realizar. Isso tem que sobreviver ao longo do tempo, tecnologias ficam obsoletas nascem uma a cada dia.

O objetivo é separar as preocupações do seu software, dividindo essas preocupações em camadas, assim como em outras arquiteturas como, por exemplo, hexagonal, mas isso não quer dizer que é a mesma coisa!

### O que é deixar limpo? 

É deixar o seu software, os fontes onde estão suas regras de negócio, o core da sua aplicação, desacoplado de fatores externos, frameworks, banco de dados, outras aplicações. Os benefícios são vários, independência de frameworks e banco de dados, testabilidade, etc.

_"Enfim, expliquei de uma forma muito didática, clean architecture tem muita coisa para entrar no detalhe"._


### Escolhas de tecnologias


> Uma boa arquitetura de software permite o adiamento dessas decisões. _**(Robert C. Martin)**_
 
Isso deve ser discutido depois, porque essas escolhas nunca devem impactar na sua arquitetura, então, porque escolher logo de início?


> Os frameworks são ferramentas a nossa disposição e não arquiteturas _**(Robert C. Martin)**_

Hoje em dia, as pessoas estão acostumadas a codificar sobre um framework específico, e acoplando todo o seu software a esse framework. Uma arquitetura limpa vai contra isso!


> Uma boa arquitetura possibilita e facilita a mudança de tecnologias _**(Robert C. Martin)**_

Um exemplo seria, você decide utilizar para camada web do software o modulo do Spring Web, se daqui a quatro anos você acha que o Spring não é mais legal ou ele ficou obsoleto, você troca o framework por outro e isso não tem impacto ao restante da sua aplicação. 

A mesma coisa se você decidir incorporar um novo banco ou mudar de bando de dados, isso deve ser feito sem esforço, sem ter que reescrever praticamente grande parte da aplicação por conta dessas mudanças. 

Seu software está nesse nível, parabéns, você tem uma boa arquitetura e limpa!

## Seja um profissional

> Não finja concordar com alguém se achar que essa pessoa está errada. Discordâncias construtivas e discussões sensatas gera resultados genuinamente melhores **_Pete Goodliffe_** 

Questione os experts, estude, procure informações, levante o dedo e diga, eu não concordo, eu acho que isso está equivocado, eu acho que não devemos seguir assim, confie em você! 

Pense no lado da empresa, gastando muito para ter e manter a melhor tecnologia, infraestrutura e arquitetura para suas aplicações. E seu departamento de engenharia muita das vezes está indo contra tudo isso, tomando decisões erradas e muita das vezes sem nenhum questionamento ou acompanhamento. 

Essas pessoas que não agem assim, e na maioria das vezes não é intencional tá? Elas são rotuladas como experts, brabos, monstros, sabe muito, são feras, etc.

Mas falta muito para esse dev ser realmente um profissional, falta fundamento, saber ouvir e discutir, pensar que talvez você possa estar errado. Muita das vezes é difícil conduzir esse dev para o caminho do profissional.

## O expert e o profissional

O dev expert conhece tecnicamente as tecnologias mais atuais, linguagens de programação e codifica mostrando toda a sua habilidade. 

Expressões lambdas complexas, códigos extremamente genéricos, resolve o problema aplicando a melhor técnica e tem o costume de criticar outras abordagens diferente da sua. Normalmente esse dev tem um milhão de pessoas perguntando como funciona tal coisa, como roda o projeto local, etc.

O dev profissional é aquele que sabe e entende que clareza é fundamental! Manter algo simples possibilita entendimento, fácil manutenção e criação de novas funcionalidades.

Normalmente esse dev não tem muita gente perguntando como funciona tal coisa ou como roda o projeto local.

## Conclusão

Hoje eu vejo que a figura de uma liderança técnica que além de ser um líder tem uma bagagem técnica está cada vez mais escassa, estão adotando muito a figura de um líder ou gestor com muito pouco conhecimento técnico. 

Eu acredito sim, que um líder técnico não precisa ser um especialista em tudo para desempenhar um bom trabalho, mas, sua posição exige um conhecimento que não pode ser superficial. 

Times ficam cada vez mais autônomos e sem acompanhamento das suas decisões, e com isso sempre fica aquele expert que _"sabe de tudo"_ tomando todas as decisões dentro do time, e apoiado pelo líder do time muita das vezes.

O resultado disso são aplicações construídas que em alguns meses está pior que a legada, não tem ganho para o negócio, para o usuário e nem para engenharia. As aplicações já nascem cheias de débitos técnicos onde nunca entra na (sprint), o software já nasce condenado.