O que escolhi não construir: Decisões que tomei enquanto criava minha plataforma de treinamento usando Elixir

Como qualquer desenvolvedor por aí, eu adoro começar projetos pessoais. Mas para mim eles têm um peso diferente: desenvolver um projeto pessoal me ajuda a manter conectado com minha missão pessoal.

Estou constantemente ensinando e fazendo coaching com pessoas sobre como desenvolver produtos melhores, seja em aulas de CSM/CSD, como consultor ou como mentor. Eu tenho minha cota de histórias para compartilhar durante esses eventos, mas sabe como é… embora essas histórias sejam novas e empolgantes para os estudantes, não posso dizer o mesmo depois de repeti-las uma dúzia de vezes.

E além disso… preciso de uma desculpa para colocar a mão no código. :)

O Produto

Como instrutor, tento criar simulações para que meus estudantes possam aprender pela própria experiência na maior parte do tempo. É por isso que em 2019 criei o jogo de cartas Scrumchkin, por exemplo. Mas desde a pandemia, a maioria das minhas sessões de treinamento tem sido online, o que torna muito difícil replicar o mesmo ambiente dinâmico que eu tinha com as cartas reais do Scrumchkin em um treinamento presencial.

Então, decidi que meu produto tentaria resolver esse problema:

Os estudantes devem ser capazes de aprender assuntos complexos através de experiência dinâmica e simulações.

Era um fit perfeito, afinal: tenho aulas periódicas onde posso levar o produto para um teste de campo e coletar feedback, e tenho acesso a uma comunidade de instrutores que poderiam estar interessados em experimentar o produto e fornecer um tipo diferente de feedback.

Como tudo que eu precisava era uma desculpa para começar a escrever código, fiquei satisfeito com isso.

Decisão: Escolha uma biblioteca de componentes UI desde o início e continue com ela. Você pode mudar tudo depois, se necessário.

Decisões de Ferramentas

Decidi evitar usar um banco de dados no início, até descobrir que tipo de dados quero armazenar e como quero armazená-los.

Elixir (minha linguagem preferida) tem algo que faz o trabalho muito bem: GenServers. Posso usá-los para armazenar dados temporariamente sem precisar recorrer a um banco de dados. A informação estará lá até que uma de três coisas aconteça:

  • Eu reinicie o servidor

  • Um erro ocorra e o GenServer seja reiniciado

  • Eu termine o GenServer

Essa abordagem me permitiu mover mais rápido e esquecer migrações, por exemplo.

Mas, mas… Mario! Não é arriscado?

Risco depende do contexto. Minhas sessões de treinamento são curtas, e no pior cenário eu perderia cerca de 15 minutos de tempo e os estudantes teriam que reiniciar um exercício se um GenServer falhar durante o treinamento.

Então, é um risco que estou conscientemente disposto a assumir.

Falando em falhas…

Não posso dizer que estou fazendo TDD puro, mas estou escrevendo muitos testes. Especialmente porque estou usando Claude para gerar alguns pedaços de código para mim (vou escrever depois sobre quais pedaços de código o Claude está escrevendo para mim).

É muito difícil usar TDD com um LLM. Esses modelos geram pedaços enormes de código de uma vez. Enquanto isso, TDD é todo sobre aquele ritmo incremental: um teste, faz passar, e depois ataca o próximo. O que estou fazendo é escrever testes para meus GenServers, pedir ao Claude para sugerir testes extras que eu possa ter esquecido e então pedir ao Claude para implementar as funções que fariam os testes passar.

Aprendi que testes agora são muito mais importantes do que eram antes da IA. Quando um LLM faz dezenas de mudanças no seu código, é impossível para você garantir que seu código ainda faz o que deveria fazer. E o Claude quebrou meus testes mais vezes do que eu consigo contar, especialmente quando tentou modificar muitos arquivos de uma vez.

Decisão: Usar IA como copiloto aumenta a necessidade de testes automatizados. E a IA também pode te ajudar a escrever seus testes.

Decisões de Design

Adquiri o tailwindui há muito tempo e gosto de usar seus blocos de construção para criar minhas aplicações. Posso usá-lo para deixar meu produto bonito sem gastar muito tempo refinando demais meu design.

Claro, sendo um não-designer eu também tenho dificuldades com o layout geral. Mesmo tendo blocos bonitos para trabalhar, ainda sou bem capaz de bagunçar tudo quando os junto. Então, às vezes uso Lovable para entender melhores formas de visualizar como os componentes poderiam ficar juntos.

Decisão: Tente adiar ter um banco de dados. Pense em diferentes formas de fazer isso para que você possa aprender mais sobre seus dados antes de se comprometer com uma estrutura de modelo.

Mecanismo de Autenticação

Quando estou em uma sessão de treinamento, não quero que meus estudantes criem contas e lembrem senhas para uma experiência que vai durar 2 ou 3 dias. Também não quero gastar tempo mexendo com um mecanismo de autenticação.

Agora, sei que alguns de vocês estão pensando: “Ei Mario, é 2025! Você pode configurar um mecanismo de autenticação em alguns minutos”. Talvez sim, talvez não. Mas tenho certeza de que ter um mecanismo completo de autenticação instantaneamente adicionaria pelo menos um pouco de complexidade a tudo mais que quero desenvolver.

Então meu mecanismo funciona assim:

Você me diz seu nome, eu salvo na sua sessão e pronto. A não ser que você seja o instrutor, é claro. Então tudo que você tem que fazer é digitar seu nome como SUPER_SECRET_PASSWORD e você terá acesso a funcionalidades avançadas.

É seguro? Não.

É bom o suficiente para usar em uma aula com 20 pessoas? Definitivamente sim.

Decisão: Autenticação vem no último momento responsável. Pense nisso, trabalhe em volta disso e talvez você acabe criando algo inovador.

Deploy

Recentemente li o incrível livro Simplicity do Dave Thomas, e há muitas boas ideias lá. Uma que particularmente gosto é: automatize seu deploy desde o dia zero, para que você possa fazer deploy frequentemente.

Fiz isso usando github workflows e minha dedibox na Scaleway. Agora faço deploy fazendo apenas um simples:

git push origin deploy

E claro, o deploy ocorre apenas se todos os meus testes passarem. Coisas bem básicas, eu sei. Mas fazer isso desde o dia um me permite fazer deploy frequentemente e coletar feedback rapidamente.

Decisão: Crie um hello world, faça deploy e automatize todo o processo de deployment antes de fazer qualquer outra coisa.

Considerações Finais

Um bom projeto pessoal é um projeto pessoal que você pode rapidamente fazer deploy e ter outras pessoas usando. No meu caso, como instrutor, a ideia de criar uma plataforma para simular coisas da vida real durante sessões de treinamento parece ser um fit perfeito.

Vou revisitar algumas dessas decisões? CLARO! Essa é toda a ideia por trás de cada uma dessas decisões. Um dia vou ter um mecanismo de autenticação adequado e um banco de dados, mas quando esse dia chegar vou ter uma razão para implementar essas coisas.

Como Jaqen de Game of Thrones diria:

O que dizemos para nossa necessidade de implementar autenticação em nossos produtos? Hoje não.

Linguagem importa: Uma demo não é uma review
As armadilhas do desenvolvimento aumentado por IA, parte 1