Redux e a importância de manter a sanidade

Já se deparou com mudanças bruscas nos estado interno dos seus softwares? Variáveis que não pareciam fazer sentidos e que demandavam horas e horas de debug
Ter que colocar um log em várias partes do programa para saber qual fluxo está sendo executado e o estado em cada etapa?
Arrancou um punhado de cabelos e acusou o computador de estar ficando louco?

Imagino que pelo menos uma das situações anteriores já deva ter acontecido com você e infelizmente, é mais comum do que gostaríamos que fosse na maioria dos casos.

As aplicações atuais costumam fugir do modelo “tradicional” onde os dados e atualizações dos mesmos, são recebidos apenas por input direto da pessoa utilizando o software. (Os famosos forms)

Hoje em dia, as aplicações têm de lidar com diversas fontes de atualizações diferentes, sejam requisições HTTP assíncronas, notificações Push, WebSockets, WebRTC, RPCs, eventos de WebWorkers, etc… Isso só para mencionar alguns.

Toda essa gama de tecnologias nos possibilita desenvolver aplicações melhores e continuar movendo a Web adiante, mas como muitas pessoas já apontaram, algumas vezes isso pode gerar uma certa dor de cabeça para se manter atualizado em tudo que está ocorrendo e principalmente para manter o código organizado.

Manter a sanidade nestes momentos é fundamental. É muito fácil se perder neste emaranhado de atualizações, condições, frameworks e bibliotecas que visam ajudar, mas que podem acabar atrapalhando a longo prazo. Com tantas opções disponíveis, fazer uma escolha que acaba se mostrando inadequada a medida que a base de código vai aumentando e novos requisitos são adicionados é muito fácil.

Nesses momentos, é preciso não ter medo de mudar e aceitar que algumas soluções (sejam frameworks ou bibliotecas) devem dar lugar a outras mais adequadas. É importante lembrar que todas estas ferramentas deveriam estar te ajudando a solucionar um problema, pois software de qualidade deve gerar valor para a pessoa que irá utilizá-lo. Caso o seu software esteja difícil de atualizar, possui um código não testado e você não tem confiança de alterar partes que não entende por completo, é um sinal que uma mudança é necessária.

Recentemente, em um projeto que eu estava trabalhando, percebemos a necessidade de controlar melhor o estado de uma aplicação que recebia atualizações de diversas fontes de dados diferentes e decidimos utilizar a biblioteca Redux, que é baseada nos conceitos da abordagem Flux, do Facebook e visa permitir que mudanças de estados sejam previsíveis.

A biblioteca em si nos foi muito útil, pois permitiu mitigar praticamente todas as situações do começo do artigo, mas algo que me chamou bastante a atenção foi uma frase deste artigo.

You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
Em HUEHUEBR:
“Você sabe quando você precisa do Flux. Se você não ter certeza, você não precisa.”

No nosso caso, o Redux nos permitiu acompanhar o estado da nossa aplicação e manter um pouco da sanidade em meio a um projeto com diversas mudanças, além de facilitar a entrada de novas pessoas a equipe. O resultado só foi positivo porque nós analisamos as necessidades e escolhemos uma solução que se encaixava na nossa situação. Utilizar bibliotecas e conceitos com o objetivo de apenas estar atualizado não é eficaz, é um tiro no pé.

Nota: Caso você queira uma introdução bem completa ao Redux pode ler esse artigo que é um excelente ponto de entrada.

Conclusão

No final das contas, o bom e velho bom senso acompanhado de uma análise técnica imparcial é nossa melhor escolha. É importante não ter medo de mudar e principalmente, cortar os laços com framework XYZ apenas por familiaridade ou gosto pessoal.

E você? Já utilizou frameworks que não precisava ou se encontrou no meio de um emaranhado de bibliotecas diferentes?