Relato: mais uma vez o planejamento prévio salvou horas do meu trabalho
TL;DR Iniciei o desenvolvimento de uma aplicação mobile em Flutter e percebi que uma das dependências que eu estava utilizando possuia um bug na qual eu não teria outra alternativa a não ser removê-la de meu projeto. No entanto, graças ao uso de uma estrutura e arquitetura bem planejadas, a refatoração desse código será de extrema facilidade. Por tanto o meu conselho é: dediquem tempo no início de seus projetos para garantir que eles poderão crescer com saúde. Os resultados a curto e a longo prazo são valiosos.
--
Olá pessoal, trago aqui para vocês um breve relato que eu acredito que pode contribuir principalmente para quem está iniciando na área de programação.
Contexto: Para quem não se lembra, recentemente eu comecei o desenvolvimento de uma aplicação mobile para consumir as APIs públicas do TabNews (https://github.com/higorpo/tabnews-mobile), sendo que utilizei o Flutter para tal e tratei de empregar as boas práticas de desenvolvimento de software como TDD, Clean Code e Clean Architecture. Além disso, tomei como decisão de projeto não acoplar minha aplicação diretamente com dependências externas, por entender que essas poderiam ser alteradas durante o desenvolvimento do projeto e que isso não deveria demandar um esforço tão grande para realizar mudanças e/ou refatorações.
O que eu não imaginava é que eu teria os benefícios dessas decisões de projeto tão rapidamente. Durante o desenvolvimento do projeto eu utilizei uma dependência externa para gerenciamento de estados e rotas conhecida como GetX (https://pub.dev/packages/get), e apesar de ser uma biblioteca amplamente utilizada para o desenvolvimento de aplicações dentro do ecossistema do Flutter e ser super bem mantida e testada pela comunidade, acabei descobrindo um bug da ferramenta que quebra a minha aplicação. Pesquisando um pouco mais a fundo sobre o problema que eu encontrei, descobri que provavelmente eu não teria outra opção a não ser remover o uso do GetX para o gerenciamento de estados e utilizar as próprias ferramentas nativas do Flutter.
Conclusão: terei de refatorar minha aplicação para remover a dependência dela ao GetX e utilizar o recurso de Streams nativo do Flutter. Se eu não tivesse me preocupado desde o início com a saúde a longo prazo da minha aplicação e aplicado testes, uma boa arquitetura e uma boa estrutura, eu provavelmente estaria desesperado neste momento (ou não, considerando que ainda estou nos estágios iniciais da aplicação, mas imagine um grande aplicativo em produção com milhares de linhas de código).
Entretanto, dado que eu me preparei para esse momento, alterar entre uma implementação e outra (GetX ou Streams) será de extrema facilidade. Em minhas contas serão dois arquivos de produção e dois arquivos de teste impactados. Nada além disso.
O que fica de aprendizado e o que eu quero passar com essa história: dediquem tempo no início de seus projetos para pensar e garantir que seu projeto poderá crescer com segurança e saúde a medida que mais features vão chegando. O tempo gasto pensando e arquitetando uma boa estrutura de projeto é infinitamente recompensado no futuro (e as vezes nem demora tanto tempo para colher resultados, como foi no meu caso).