Flutter — Construindo um Projeto Boilerplate perfeito do zero. Parte 2: Ponto de dor

Crédito: Nguyễn Thành Minh (Desenvolvedor Android)

Por meio deste artigo, apresentarei a você 5 pontos problemáticos que experimentei enquanto desenvolvedor móvel. Formei alguns critérios que precisamos na arquitetura. Por fim, também contarei a história de como a Clean Architecture me ajudou a resolver esses pontos problemáticos.

1. Cinco pontos problemáticos no passado

1.1. As difíceis decisões do líder

Fonte: Unsplash See More

O ponto problemático de todo líder ou arquiteto vem de ter que tomar decisões.

O líder deve decidir qual estrutura, biblioteca, banco de dados e tecnologia esse projeto deve usar. Uma decisão precipitada ou falta de visão levará a consequências imprevisíveis no processo de desenvolvimento de software. Portanto, como líder de projeto, estou sempre procurando uma arquitetura que me ajude a atrasar a tomada de decisões o máximo possível, mas ainda garantir que a equipe não precise esperar que eu pense, minha equipe fica à frente. Mesmo que a equipe de design ainda não tenha desenhado nenhuma tela, nossa equipe ainda pode fazer a lógica primeiro e escrever o teste de unidade normalmente.

1.2. Durante a manutenção do projeto, corrigir 1 bug criará 10 novos bugs

Fonte: Unsplash See More

Isso não é incomum para desenvolvedores quando precisam refatorar ou corrigir bugs em um projeto com uma “arquitetura extremamente rígida”. Classes e funções estão tão intimamente relacionadas entre si que apenas consertar uma pequena função é suficiente para explodir todo o projeto. Em alguns cenários, após corrigir 1 bug, o testador encontrará mais 10 bugs, portanto, pode levar meses para corrigir apenas 1 bug. Isso torna o custo de manutenção do projeto muito alto, então precisamos de uma arquitetura que ajude a separar ao máximo as dependências. Para que toda vez que editarmos uma classe ou uma função, todo o sistema não seja afetado e você não precise corrigir o código manualmente.

1.3. Os pontos problemáticos do desenvolvedor FE podem vir do desenvolvedor BE

O desenvolvedor FE cujo código da classe Model é baseado na API Response definida pelo desenvolvedor BE terá 4 riscos:

1. Se BE for mal projetado, FE também será afetado, o código é muito difícil de mapear com UI, requer muitos cálculos para mapear com UI. Como na foto acima, o Json Response está do lado direito, no modelo Booking existe um modelo Room; e no modelo Room, existe um modelo Booking, que fica repetindo sem parar.
2. O FE terá que se adaptar ao BE, mas as classes Model são importadas para muitas classes como UI e Bloc. Consertá-lo levará à modificação em massa das classes que dependem dele.
3. Dois desenvolvedores BE em uma equipe podem ter dois estilos de codificação diferentes, portanto, podem retornar UserDatarespostas muito diferentes, dependendo das APIs. Por exemplo, na fetchUsersAPI, eles retornam o agecampo do tipo int?, mas na fetchUserDetailAPI, eles retornam do tipo String?. E se eu declarar o campo age do tipo int?? Meu aplicativo falhará ao chamar a fetchUserDetailAPI. Portanto, devemos declarar o agecampo do tipo dynamicmesmo que esse tipo seja considerado inseguro, pois pode facilmente resultar em erros de execução. Este caso é muito comum quando se trabalha como freelancer, quando os membros da equipe BE nunca trabalharam juntos antes e não há líderes e ninguém revisa o código.
4. Por segurança, todos os campos nas classes de modelo de dados sempre devem ser tipos anuláveis, como int?, String?. No entanto, isso pode levar ao risco de nosso aplicativo travar devido a arquivos NullPointerException.

1.4. Faça o aplicativo móvel e o aplicativo de TV em um repositório

Anteriormente, participei de um projeto para desenvolver aplicativos móveis e aplicativos de TV como o Youtube. Naquela época, tive que criar 2 módulos de aplicativo: mobile_app, e tv_app. Vale ressaltar aqui que esses dois módulos usam a mesma API de requisição como fetchVideos, fetchVideoDetail. Assim, para reutilizar o código da requisição da API para ambos os módulos, precisamos projetar a arquitetura de forma que a parte da API seja separada em outro módulo para injetar nesses dois módulos do app.

1.5. A história da tartaruga e da lebre e a falácia clássica do desenvolvedor

Olhando para dois gráficos estatísticos acima. Os desenvolvedores podem ver isso como normal, já que isso é algo que encontramos muito. Mas para os gerentes, eles certamente ficarão preocupados. Eles querem gastar mais dinheiro para obter maior receita e maior produtividade após cada lançamento, mas a vida não é perfeita. Na verdade, os projetos precisam apenas de 20% do custo total para criar 80% das principais funcionalidades de um software. Porém, nas próximas versões, adicionar algumas funcionalidades aos poucos pode custar muito caro, em alguns casos, pode até causar incidentes com consequências gravíssimas. A arquitetura certamente desempenhou um papel importante na causa desse problema.

Vamos relembrar a lição sobre a Lebre e a Tartaruga que aprendemos na infância. Podemos conduzir três lições para nós mesmos:

• Devagar e sempre vence a corrida
• A vitória não depende de quão forte ou rápido você é
• Quanto mais pressa, menos velocidade

Uma falácia comum dos desenvolvedores é “O prazo do projeto está chegando, codifique o que quiser e refatore depois”. Pensar assim trará dois grandes problemas:

1. Não há tempo para refatoração. Pessoalmente, também experimentei e testemunhei muitos outros desenvolvedores gastando seu tempo livre nos fins de semana para refatorar novos recursos lançados no último sprint. Este é um hábito de trabalho pouco saudável.
2. Não há garantia de que a refatoração funcionará e não criará mais bugs.

Concluindo, esses são meus 5 pontos problemáticos que encontrei durante meu tempo como desenvolvedor móvel. Na última parte, revelarei: Como a Clean Architecture me ajudou a resolver esses pontos problemáticos.