Executando verificação de segurança...
1

React - Clean Architecture! [Quero a sua opinião!!!]

Fala pessoal, meu nome é Pietro sou desenvolvedor frontend a aproximadamente 8 anos e já trabalhei em algumas empresas ao longo da minha carreira. Nunca tive a oportunidade de trabalhar em uma empresa referência em tecnologia (é uma meta para atingir até os 30 anos), mas por onde passei os projetos sempre eram organizados de forma bem parecida, uma pasta para páginas, outra para hooks, outra para utils, arquivos de comunicação com apis...

Recentemente peguei alguns dias para estudar Clean Architecture e pensar em como poderia aplicar isso em um projeto frontend (ReactJS ou Flutter). Fui comparando as boas práticas com tudo que já fiz, percebi algumas semelhanças e em outros pontos muitas divergências.

A minha principal referência de Clean Architecture para frontend foi um curso do Rodrigo Manguinho e vendo a forma com que o código fonte foi feito me levantou muitos questionamentos que me fizeram encher o saco de muitos amigos sobre o assunto.

Abaixo vou deixar um exemplo de um fluxo de requisição de login construida no projeto Clean React

signup-factory.tsx

export const makeSignUp: React.FC = () => {
  return (
    <SignUp
      addAccount={makeRemoteAddAccount()}
      validation={makeSignUpValidation()}
    />
  )
}

signup-validation-factory.tsx

export const makeSignUpValidation = (): ValidationComposite => ValidationComposite.build([
  ...Builder.field('name').required().min(5).build(),
  ...Builder.field('email').required().email().build(),
  ...Builder.field('password').required().min(5).build(),
  ...Builder.field('passwordConfirmation').required().sameAs('password').build()
])

remote-add-account-factory.ts

export const makeRemoteAddAccount = (): AddAccount =>
  new RemoteAddAccount(makeApiUrl('/signup'), makeAxiosHttpClient())

api-url-factory.ts

export const makeApiUrl = (path: string): string 
    => `${process.env.API_URL}${path}`

axios-http-client-factory.ts

export const makeAxiosHttpClient = (): AxiosHttpClient 
    => new AxiosHttpClient()

axios-http-client.ts

export class AxiosHttpClient implements HttpClient {
  async request (data: HttpRequest): Promise<HttpResponse> {
    ... aqui toda a lógica da request usando axios
  }
}

Eu não tenho dúvidas que esse é um código bom! Totalmente modular, testável, com muitas abstrações, totalmente reutilizável e de fácil manutenabilidade

...mas...

  1. da para exigir que um time com diversos níveis de profissionais entreguem códigos assim?

  2. tantos arquivos e funções não prejudicam a legibilidade?

  3. esse tipo de organização é comum onde você trabalha?

Qual a sua opinião? Seria essa a bala de prata para deixar de criar códigos ruins? O Clean Architecture está obsoleto e deixa os códigos verbosos demais?

Carregando publicação patrocinada...
1

Vou falar como um dev que mergulhou no seu primeiro estágio já em código com Clean Architecture:

Os primeiros dias foram terríveis, porque além de eu não saber nada sobre o framework que eu iria enfrentar (No caso, Android), eu ainda tinha que me acostumar com a linguagem (Kotlin) e com monstruosidade de códigos que a Clean Architecture trazia. Uma das principais perguntas que eu fazia a mim mesmo era: "Por que isso tem que ser feito assim? Por que eu não posso simplesmente colocar aquela classe dentro dessa tela e chamar os métodos diretamente? Por que tantos arquivos e segmentações???"

Eu só fui começar a entender o porquê disso tudo meses depois. A medida que o projeto foi crescendo com novas funcionalidades e também a medida que fomos criando novos testes unitários, fui percebendo que, em um caso onde tudo estivesse juntinho, não seria possível fazer um teste unitário sequer. O código se tornaria imprevisível e suscetível a muitas falhas.

No projeto atual onde trabalho, a nossa parte de regras de negócio tem mais linhas de código de testes unitários do que realmente funcionalidade implementada, mas eu te garanto: Fazer adições no código e depois apenas rodar os testes unitários pra ver se ainda tudo funciona como deveria é uma sensação incrível.

Ok, voltando ao centro do assunto...

Respondendo a sua primeira pergunta:
1 - Sim, dá pra exigir que diversos profissionais de diversos níveis entreguem códigos assim.

No começo, a maior parte do meu tempo era estudando e estudando e estudando (e estudando...) aquela enorme estrutura de código. Era simplesmente muita coisa pra entender de uma vez só. Porém com o passar do tempo as coisas começam a fazer sentido e o novato vai pegar o jeito, mas uma coisa é certa: ele precisará de tempo e apoio. Pense que você vai ter que dedicar uma parte considerável do seu tempo ajudando o time a entregar um código dentro da estrutura que você quer. Mas é claro, a medida que o time amadurece, essas outras pessoas vão poder ajudar a si mesmas e tudo vai começando a ficar muito mais fácil.

2 - Para um código pequeno sim, com certeza atrapalha muito a legibilidade. Mas a medida que ele cresce, os arquivos começam a fortalecer seus propósitos e a legibilidade começa a ganhar.

3 - Não exatamente esse tipo de organização do seu exemplo pois nunca achei esse tipo de Clean Architecture antes, mas minha maior referência (e a que mais encontro nos locais onde já trabalhei) é essa publicação de Guilherme Biff Zarelli no Medium. Essa eu encontrei exatamente igual a essa ou similares em todos os locais onde trabalhei.

1

Experiência própria

Parando pra pensar nas suas dúvidas, acabo me questionando sobre elas também, então vou dar minha opinião como estudande da área.
Gosto mais da parte da arquitetura do software (dessing patterns e padrões de projetos) do que criar interfaces, o que me leva a consumir conteúdos sobre tais assuntos.
Fazendo os trabalhos e atividades da faculdade, percebo que muitas pessoas não se interessa sobre esses assuntos e so querem fazer um código que funcione, e já ouvi muitos falar que isso deixa o código mais complicado e difícil de entender, sei que arquitetura de software não é cobrado em certas circunstâncias, mas acho importante conhecer alguns padrões de projetos, como o MVC por exemplo.
No final, esse tipo de conhecimento só é adquirido com o tempo mesmo, não é algo que se uma pessoa pode facilmente ensinar pra outra.

Às dúvida

Ralmente não dá pra exigir com que um time com níveis tão diferentes criem códigos parecidos, principalmente quando se mexe com desing patterns, pois a aplicação deles se devem de um problema específico, e pra quem tá começando é difícil identificar e aplicar o pattern certo.
Não acho que muitos arquivos atrapalhe, pelo contrário, acho que ajudam na divisão de conceitos. Eu gosto de usar e abusar da criação de pastas para definir um contexto específico para determinada funcionalidade por exemplo, assim quando preciso mexem em algo, ja sei onde ele provavelmente pode estar.
Eu não trabalho aínda, mas no ambiente acadêmico não é tão comum ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯.