O VBank começou com uma ideia que parecia bem controlada na minha cabeça: criar um banco fictício com contas, usuários, saldo e transferências, mas com estrutura suficiente para ser tratado como uma aplicação de verdade. Não precisava competir com um banco real, obviamente. Eu queria um projeto em que as peças tivessem que conversar entre si e em que uma funcionalidade não terminasse no momento em que o método retornava o valor certo.
A parte do “bem controlada” durou menos do que eu esperava. Conforme o projeto ganhou backend, banco de dados, frontend e automações, cada nova camada trouxe perguntas que não apareciam no código isolado. O VBank funciona hoje, mas chegar até esse ponto me ensinou que colocar uma aplicação de pé é só metade do trabalho. A outra metade começa quando ela precisa funcionar de forma previsível fora da minha máquina.
Quando a ideia simples começa a crescer
No papel, uma transferência parece direta: conferir os dados, validar o saldo, retirar de uma conta e adicionar em outra. Na aplicação, essa ação também precisa lidar com persistência, respostas da API, possíveis falhas e o estado que o usuário vê enquanto tudo acontece. Cada parte pode estar correta sozinha e, mesmo assim, a experiência completa ainda parecer estranha.
Foi justamente esse crescimento que tornou o projeto interessante. Em vez de manter tudo pequeno só para terminar rápido, comecei a usar o VBank para praticar decisões que aparecem em sistemas maiores. Como separar responsabilidades? O que precisa ser validado no backend? Como o frontend comunica que uma operação está em andamento? O que acontece quando o ambiente remoto não se comporta como o local? Essas perguntas fizeram o projeto render muito mais aprendizado do que a ideia inicial sugeria.
Java não era o maior problema
Uma das descobertas mais engraçadas do desenvolvimento é perceber que escrever a funcionalidade nem sempre é a parte que mais dá trabalho. Em vários momentos, implementar a lógica em Java foi mais tranquilo do que descobrir por que uma etapa da automação tinha decidido parar de colaborar sem mandar um aviso compreensível.
Isso não significa que o backend tenha sido automático. Modelar regras, lidar com dados e manter a lógica organizada exigiu bastante atenção. A diferença é que, quando um erro acontecia no código, eu normalmente tinha uma linha, uma exceção ou pelo menos um comportamento que conseguia reproduzir. No pipeline, às vezes o problema aparecia em um ambiente distante, depois de alguns minutos, com uma mensagem que parecia ter sido escrita para encerrar a conversa.
Foi aí que as GitHub Actions deixaram de ser apenas um arquivo de configuração e viraram parte real do projeto. Build, variáveis, versões e pequenas diferenças de ambiente começaram a importar. Em certas sessões eu passei mais tempo discutindo com YAML do que escrevendo Java — e confesso que o YAML ganhou algumas rodadas.
Quando o pipeline entra na conversa
No começo, ver o código funcionando localmente dava aquela sensação confortável de tarefa concluída. O pipeline tratou de acabar com essa ilusão. Uma dependência podia existir na minha máquina e faltar no ambiente de execução; uma variável configurada localmente precisava chegar ao lugar certo; um comando simples podia ter um comportamento diferente por causa da versão usada no runner.
Esses problemas são chatos enquanto acontecem, mas são úteis porque expõem dependências invisíveis. Se o projeto só funciona em um computador que já está preparado há meses, ele não está tão reproduzível quanto parece. Fazer a Action ficar verde não é só buscar um selo bonito no repositório: é transformar o processo de construir e validar a aplicação em algo que outra máquina consegue repetir.
Claro que teve a sequência clássica: “por que falhou agora?”, seguida de “mas passou na execução anterior” e, por fim, “eu literalmente não mexi nisso”. Nessa hora a melhor opção costuma ser sair do drama por cinco minutos, voltar para os logs e verificar cada suposição. Quase sempre existe uma causa; ela só não tem obrigação nenhuma de ser óbvia.
O famoso “funciona, mas…”
Atualmente o VBank funciona, e essa frase vem acompanhada de um mas importante. Algumas operações que dependem do banco de dados ainda apresentam um tempo de resposta irregular. Em certos momentos a resposta chega rápido; em outros, alguns segundos aparecem entre o clique e a atualização da interface.
Tecnicamente, a operação termina e os dados ficam corretos. Para quem está usando, porém, esses segundos mudam a percepção do sistema. A pessoa clica, a interface parece parar e só depois confirma o que aconteceu. Mesmo quando o backend está fazendo exatamente o que deveria, a falta de uma resposta visual imediata faz a aplicação parecer mais lenta — ou pior, quebrada.
Eu não quero esconder isso atrás de uma frase bonita de portfólio. O comportamento ainda está sendo investigado e pode envolver mais de um ponto: a forma como algumas consultas são feitas, a comunicação entre os serviços, o ambiente em que o banco está hospedado ou o jeito como o frontend representa estados de carregamento. Antes de escolher uma “otimização”, preciso medir onde o tempo está sendo gasto. Senão eu só troco código e torço para melhorar.
Fazer funcionar e fazer parecer rápido
O VBank deixou bem clara a diferença entre uma funcionalidade correta e uma experiência boa. Uma transferência pode ser concluída sem nenhum erro e ainda gerar insegurança se a tela ficar parada durante o processo. Da mesma forma, uma API pode devolver os dados certos e precisar de melhoria porque demorou mais do que o contexto permite.
Parte da solução está no desempenho real: reduzir consultas desnecessárias, observar latência e entender os gargalos. Outra parte está na interface: indicar carregamento, evitar cliques repetidos, explicar quando uma etapa leva mais tempo e atualizar o que for possível sem deixar o usuário no escuro. Não é maquiagem para um backend lento; é reconhecer que comunicação também faz parte do funcionamento.
Essa visão mudou meu critério de “pronto”. Antes, eu poderia considerar uma tarefa encerrada assim que o resultado aparecesse corretamente. Agora tento olhar o percurso inteiro, do clique até a confirmação, porque é nele que os pequenos desconfortos ficam evidentes. O projeto passa a revelar problemas mais interessantes justamente quando já funciona o suficiente para ser usado.
Um projeto público também mostra o processo
O VBank continua em desenvolvimento porque já saiu da fase de provar que a ideia é possível. Agora ele pode melhorar em pontos mais difíceis de perceber num exemplo pequeno: sensação de velocidade, feedback da interface, confiabilidade do pipeline e comunicação com o banco. São detalhes menos chamativos que uma tela nova, mas fazem diferença quando as peças precisam trabalhar juntas.
Manter o repositório público também significa deixar esse processo visível. Ele não mostra apenas uma aplicação “finalizada”; mostra alterações, tentativas, correções e decisões que foram mudando com o tempo. Para mim, isso é mais honesto e também mais útil do que fingir que todo projeto nasce organizado e segue uma linha reta até a última versão.
Ainda devem existir alguns erros esperando pacientemente a vez de aparecer. Quando eles chegarem, a ideia é entender o motivo, corrigir sem criar três problemas novos e registrar o que aprendi. Se der para cumprir pelo menos duas dessas três coisas, já considero uma boa rodada.