Como escolher dependências no Flutter?

Voce sabe como escolher as melhores dependências para seu projeto em Flutter? Seja voce um Junior ou Senior, Novato ou Expert. Com minha experiencia através de mentorias e treinamentos a um bom tempo neste meio, estive observando vários casos onde projetos se tornavam cada vez mais complexo pela falta de planejamento na hora da escolha de dependências externas e isto pode ser muito caro no futuro. Com base nisto escrevo minha OPINIÃO sobre quais as melhores praticas e pontos de reflexão importantes na hora de realizar essas escolhas.

Começo dividindo em duas categorias, sendo elas, Design e Funcionalidade.
A dependência de Design seria aquela onde estaríamos adicionamento em nossa aplicação um componente já pronto e customizado (Custom Widget), como por exemplo um botão personalizado, uma barra de buscas ou até mesmo uma BottomSheet personalizada.
Temos também dependências de Funcionalidade, essas seriam responsáveis por adicionar utilitários de ferramentas prontas para utilizarmos em nosso projeto, tais como, Firebase Crashlytics, Dartz e praticamente todas gerências de estado.

Quando estou construindo uma aplicação um dos primeiros pontos que penso é em relação a arquitetura base da minha aplicação, quais pontos de flexibilidade e rigidez ela terá e onde esses ficarão. Esse estudo de arquitetura inicial é imprescindível para o sucesso da minha aplicação e a escolha das dependências e quais limites arquiteturais estou disposto a implantar ou ceder.

Não sou totalmente purista ao ponto de falar "Devemos sempre utilizar tudo do flutter, ser agnóstico a dependências e bla bla bla" porém sempre que possível gosto de ter o controle total da minha aplicação, dependências de Design são mínimas ou até mesmo inexistente caso seja plausível é claro, reconheço que em alguns casos não precisamos reinventar a roda, porém muita cautela com isto meu querido padawan! Quando utilizo este tipo de dependência, sempre levo em conta os seguintes items.

• Data de publicação X última data de atualização do package.
• No Github do projeto (possível acessar via pub.dev), o package tem testes escritos? os testes estão funcionando? O coverage é aceitável? (em minhas métricas gosto de entender aceitável para o mundo do Flutter, acima de 85%)
• O Autor do package é aberto a sugestões de alteração e colaboração da comunidade? (Verifico também no Github, pelas issues abertas, colaboradores e pull requests)
• Caso eu necessite mudar este componente em algum momento, qual será o impacto em minha aplicação? (Posso criar uma abstração em cima deste componente e utilizar ela em toda aplicação, deixando somente um lugar para mudar caso seja necessário?)
• Eu realmente preciso dele ou posso fazer na mão? Caso eu tenha que atualizar a versão do Flutter este package ainda funciona corretamente?

Quando estamos tratando dependências de Funcionalidade gosto de utilizar o jargão popular "O buraco é mais em baixo" pois aqui é onde mora o perigo, estas dependências são muito maléficas se não tivermos limites arquiteturais bem definidos. É muito fácil ela se impregnar em nossa arquitetura e nunca mais ser possível substituir caso necessário, gosto então de seguir também todos os items citados acima e mais alguns, sendo eles:

• Sempre que adiciono uma dependência de funcionalidade como por exemplo firebase analytics, crio um interface (abstract class) com as regras de negocio que eu preciso de fato e então utilizo do padrão de projeto "Facade", para abstrair toda a complexidade para esta implementação e assim deixando o código isolado em meu sistema, este código também fica em uma parte especifica de acordo com a arquitetura que estou utilizando, não devemos misturar regras de negocio com funcionalidades do mundo externo. Outras vantagens desta pratica é a facilidade de testar se o seu contrato (interface) está realmente fazendo o que deveria e também a facilidade de em qualquer momento realizar uma nova implementação do contrato via Facade trocando o package que neste exemplo faz o crashlytics.

1. — Interface/Contrato

1.1 — Implementação utilizando Design Pattern Facade

• Na escolha de uma dependência de Funcionalidade para gerência de estado, existe inúmeras opções no mercado optei por não entrar no mérito e nem irei sugerir nenhuma, porém irei realizar os seguintes questionamentos que você pode aplicar também ao seu projeto. Eu realmente preciso desta gerência de estado? Existe uma forma mais fácil de realizar a alteração do estado? Meus widgets estão desacoplados o suficiente para utilizar setState? Como a árvore de widgets irá ser afetada nesta page caso eu decida utilizar o setState? Caso seja impactada negativamente posso utilizar outra solução nativa do flutter como ValueNotifier ou ChangeNotifier?

Após seguir todos esses passos eu sempre chego em um ótimo resultado para o problema proposto, porém vale salientar que nada disto é uma regra, como eu disse no inicio do artigo, esta é minha OPINIÃO e visão com base na minha vivência, essas métricas que escolhi compartilhar com vocês podem e devem ser alteradas com base em cada problema/projeto que vc esta enfrentando. Dito isso, eu ficaria muito feliz com a contribuição de vocês me contando quais as métricas na escolha de dependências que vc utiliza!

Me chamo Deivid Willyan, trabalho com desenvolvimento a 8 anos, tenho vasta experiencia com Java, Node, Android, iOS e Flutter, atuo como Coorganizador da maior comunidade de Flutter do Brasil (Flutterando) e palestrante, mentor e consultor Flutter.

Telegram: @DeividWillyan
Github: https://www.github.com/deividwillyan
Linkedin: https://www.linkedin.com/in/deivid-willyan-rodrigues-fabiano-19776abb