Sua teck stack não importa!

Você provavelmente já deve ter visto algum vídeo de um tech influencer compartilhando sua nova tech stack preferida. Essa stack dos sonhos conta com alta performance, ganhos de produtividade e o uso das tecnologias mais modernas, seja lá o que isso signifique. Alguns vão além e as vendem como um starter pack, contendo um exemplo, sem qualquer semelhança com uma aplicação que opera em produção. Esses starter packs costumam já estar acoplados a serviços de terceiros, como envio de e-mails, recebimento de pagamentos e provedores de hospedagem, tudo isso com a promessa de que essa tech stack irá acelerar o desenvolvimento do seu próximo projeto e te tornar um indie hacker de sucesso.

Os influenciadores tendem a encher os olhos de novos desenvolvedores que, ao verem rapidamente os resultados em tela obtidos pela adoção dessas tecnologias, ficam entusiasmados para criar um novo projeto ou mesmo aplicá-las no trabalho. No entanto, surge uma questão: no momento em que essa tecnologia não suprir sua necessidade ou surgirem problemas mais complexos, quem irá resolver? Há alguém a quem o dev júnior possa recorrer? E se não houver, ele saberá como lidar com a situação?

Perguntas

Antes de dar início a um projeto, mesmo que pequeno, é sempre importante fazer algumas perguntas. Qual é o escopo do projeto e qual é o tamanho da equipe de desenvolvedores? É um sistema que terá apenas alguns milhares de usuários ou precisa aguentar uma grande carga de trabalho durante longos períodos? Haverá a necessidade de um serviço de banco de dados com réplicas para consultas mais complexas? Existe uma equipe de DevOps para lidar com uma infraestrutura on-premise ou os próprios desenvolvedores terão que cuidar da esteira de entrega da aplicação?

Perceba que nenhuma dessas perguntas ainda levantou a questão de qual linguagem de programação, framework ou serviço de terceiros deve ser utilizado. Não é o momento para isso! Essas perguntas são muito mais fundamentais do que os detalhes de implementação e irão determinar que tipo de legado esse projeto se tornará, pois, no fim, quer você goste ou não, esse é o destino de todo sistema que está rodando em produção.

Um universo de possibilidades

Há alguns anos, enquanto editava um vídeo para uma tarefa de estágio, pedi ajuda a um colega e perguntei: “Mas essa é a maneira certa de fazer isso?”. Ele olhou para mim e respondeu que não havia uma forma certa, mas que eu deveria me atentar ao resultado. Se o objetivo foi alcançado, isso era suficiente. Levo isso comigo, não como uma máxima, mas como uma lembrança para não paralisar pensando demais. Ao assistir a um vídeo no YouTube, não costumo questionar se foram usados o After Effects, o DaVinci Resolve ou o CapCut; apenas me atenho ao conteúdo. Por que com software seria diferente?

Se você abrir uma pesquisa na área de tecnologia, como o Developer Survey do Stack Overflow, verá a quantidade de liguagens, frameworks, bancos de dados e ferramentas disponíveis para uso. Será contraprodutivo tentar aprender ou mesmo tentar conhecer todas. Mesmo em pesquisas com um público mais específico como State of JavaScript, a quantidade bibliotecas e metaframeworks disoníveis é grande. O ecossistema JavaScript é um exemplo de como pode ser cansativo tentar aprender tudo e acompanhar as novidades. Esse é justamente um dos motivos pelo qual eu não gosto desses starter pack, ou stack pra indie hacking. Sempre existe uma nova e melhor biblioteca pra resolver o mesmo problema. As recomendações estão sempre mudando até você não se lembrar mais como foi para nessa toca de coelho.

Escolhas e restrições

Em um ambiente de constantes mudanças e excesso de opções, é muito comum que você se encontre paralisado analisando as alternativas à sua disposição. E pode parecer paradoxal, mas ter muitas escolhas não é necessáriamente algo bom. A biblioteca Tailwind CSS, por exemplo, busca restringir a quantidades suas escolhas que você precisa fazer por meio das suas classes utilitárias predefinidas, dessa forma você não precisa pensar se deveria aplicar 11, 12 ou 13 pixels ao padding do botão de confirmar a compra.

No entanto, é importante se lembra que, quando se está em uma posição de tomada de decisão, delegar a escolha sempre será a pior opção, pois quem recomenda algo dificilmente será responsabilizado por um eventual problema, seja ele qual for. Mas como fazer uma escolha certa? Bom, talvez não exista uma escolha certa, mas provavelmente haverá muitas escolhas erradas e quanto menos escolhas ruins existirem, melhor. Por isso, volte ao início e lembre-se das perguntas a serem feitas. Elas ajudarão a riscar as opções da lista. Uma outra dica é escolher uma tecnologia chata, e com isso não estou sugerindo adotar Cobol, Visual Basic ou Delphi para o seu próximo projeto, mas optar por um caminho mais estavel em um ecossistema mais maduro. Dessa forma, ao longo do tempo, você terá menos surpresas e haverá uma maior chance de lidar com elas sem maiores complicações.

Além disso, tenha em mente o seu contexto. Certa vez, vi um desenvolvedor justificar a sua escolha por usar Go, alegando ser uma linguagem simples, com uma baixa curva de aprendizagem, e que já tinha tudo o que ele precisava por padrão. Tempos depois, vi outro desenvolvedor citar um momento traumático na startup em que trabalhava, pois um serviço crítico desenvolvido em Go quebrou em produção, e único desenvolvedor que tinha familiaridade com a linguagem não estava disponível. Assim, o time que era especiazado no escossistema JavaScript teve que resolver como pôde. Essas pespectivas antagônicas se dão pelo contexto dos desenvolvedores. Enquanto alguns podem achar que subir um serviço em Go é mais prático do que com Node.js, para outros pode ser um pesadelo sem fim. Por isso, escolha uma tecnologia com a qual você e sua equipe se sintam confortáveis.

O ciclo se fecha

Quando tecnologias como Angular, Backbone.js e React se popularizaram, o ecossistema JavaScript passou a trazer mais código e responsabilidades para o lado do cliente, sob o argumento de que isso iria melhorar a experiência do usuário. No entanto, essa estratégia acabou se tornando um problema, pois as aplicações inflaram seu tamanho com código, por vezes, desnecessário. Os desenvolvedores passaram a depender cada vez mais de bibliotecas de terceiros, e os novos desenvolvedores deixaram de aprender como a plataforma para a qual desenvolvem funciona, passando a aprender apenas o que a biblioteca ou framework da moda tem a oferecer.

Contudo, hoje o servidor e a web são muito mais poderosos do que décadas atrás, e alguns frameworks, como Svelte e Remix, passaram a trilhar um caminho diferente, dando foco ao que importa: a plataforma web e seus padrões Com isso, o uso de formulários web com a FormData API, aliado à melhoria progressiva, voltou a ser o recomendado para o desenvolvimento de aplicações modernas. Os server componentes, junto com as server functions, roubaram a cena como uma grande inovação, mas, no fim, são uma reinvenção de técnicas já existentes, e agora estamos devolvendo as responsabilidades que um dia pertenceram ao lado do servidor.

Conclusão

É comum ouvir na área de desenvolvimento que não existe uma “bala de prata”. No final das contas, o que realmente importa não é a ferramenta utilizada, mas o problema que se resolve. Por isso, é preciso ter cuidado ao seguir cegamente as sugestões que circulam em vídeos e blog posts. Experimentar diferentes tecnologias é importante para criar um repertório e desenvolver um senso crítico sobre qual solução adotar para cada problema. No entanto, as principais linguagens e frameworks não apresentam paradigmas de desenvolvimento tão distintos. Foque nos fundamentos e entenda como as máquinas e os sistemas que você desenvolve operam e se comunicam. Assim, migrar de tecnologia se tornará algo trivial.