Escrevi um artigo anteriormente onde contei um caso sobre um aplicativo que me custou 4 mil dólares mensais, tudo por causa da pressa (se quiser ler, o link está aqui: O Dia Em Que a Pressa Me Cobrou 4.000 Dólares por Mês
Pois bem, o conto de hoje tem tudo a ver com essa mesma aplicação. Sim, ela de novo! Mas dessa vez, a sorte estava do meu lado eu tinha backup.
Antes de começar, só uma observação: Quem não tem této de vidro, que atire a primeira pedra🙃.
Continue lendo…
O Início da Confusão
Eu e um amigo havíamos criado um aplicativo no-code para uma empresa grande. Tudo ia bem: App em produção, cerca de 50 usuários simultâneos, cliente feliz, e novas solicitações de melhorias chegando constantemente.
Em uma dessas atualizações, o cliente pediu para mudar o nome de um campo na interface, afinal, o novo nome fazia mais sentido para os usuários.
Beleza. Alterei o nome no front-end, mas o nome da coluna no banco de dados continuou o mesmo.
— Pensei: “Tranquilo, é só renomear a coluna e sincronizar, vai refletir em tudo.”
Certo? Errado! 😂
Como já tinha passado por algo parecido antes, decidi fazer tudo com calma (ou quase).
Criei uma nova coluna com o nome correto, e deixei a antiga lá, caso desse problema, eu ainda teria os dados salvos. Até aí, show. Só que na hora de transferir os dados, bateu aquela preguicinha básica...
Ao invés de usar um simples comando SQL para copiar os valores, eu pensei:
— "Ah, mais rápido jogar tudo pro Excel, copiar e colar de volta no banco."
Feito isso, tudo parecia lindo. Mas tinha um pequeno detalhe: O tipo de dado da coluna era numérico, e o Excel, bom, ele fez o que o Excel faz de melhor, estragou metade das conversões. 😂
Algumas linhas ficaram zeradas. Pensei:
—“Ah, bobagem, nada demais.” Fiz o deploy e segui a vida...
Até o telefone tocar:
—“Amigo, me socorre! Os lançamentos do ano inteiro ficaram zerados!” 😱
Sorte a minha que mantive a coluna antiga. No fundo, parecia que eu já sabia que ia dar ruim hahaha…
Comparei os dados, confirmei o erro e transferi tudo de novo, dessa vez com SQL, bonitinho. Problema resolvido… ou pelo menos era o que eu achava.
Após corrigir tudo, atualizei o nome da coluna no banco e na aplicação. Só esqueci de um pequeno detalhe: Existiam colunas calculadas (virtuais) que usavam esse nome antigo nas fórmulas.
Resultado? Os cálculos ficaram completamente errados!
O cliente, prestes a apresentar o sistema numa reunião importante (faltavam 50 minutos!), me liga desesperado. Eu, já suando frio, mexendo em tudo pra tentar resolver, e claro, na pressa, acabei quebrando a aplicação inteira. 🥲
Foram alguns minutos de puro desespero. Até que uma luz acendeu:
— “Pera aí… se mudei o nome da coluna no banco, preciso mudar também nas colunas virtuais!”
Supimpa...😀
Corrigi, sincronizei, e… milagre! Tudo voltou a funcionar! 🙌
O que dizer disso tudo?
Olha, se tem uma coisa que essa história me lembrou é que a pressa ainda é o maior bug do desenvolvedor.
E o pior é que a gente sabe disso, mas sempre acha que “dessa vez vai dar certo”. Só que o universo do código não perdoa. 😂
No dia a dia de quem trabalha com desenvolvimento, essas situações são quase rotina:
Aquele deploy que quebra bem na sexta à noite, o “só um ajuste rápido” que vira um caos
O bug misterioso que aparece só quando o cliente está na reunião de apresentação...
É quase um teste de paciência.
O problema é que a correria, a pressão e os prazos fazem a gente querer resolver tudo no impulso, e é aí que mora o perigo. Às vezes, o erro nem está no código, está na pressa de resolver.
Dessa vez eu tive sorte porque o backup estava lá, firme e forte, pronto pra me salvar da catástrofe. Mas nem sempre é assim, né?
Então ficou a lição:
Backup salva vidas. Paciência salva o deploy. E o Excel… destrói seu banco de dados com um simples “colar valores”
No fim das contas, acho que o grande aprendizado é esse: Faça com calma, teste, revise, e só depois sincronize.
Porque, por experiência própria, posso te garantir, o “Ctrl+C, Ctrl+V” é rápido, mas o retrabalho depois… ah, esse é eterno. 😅
No fim, acho que errar faz parte do caminho de quem programa. Cada bug, cada “Ctrl+C” apressado e cada tabela mal planejada ensinam algo que livro nenhum ensina.
E falando em aprender com os erros… essa não foi a primeira vez que eu causei um desastre técnico.
Se quiser entender de onde vem toda essa “bagagem de gafes”, dá uma olhada no artigo onde conto a primeira delas, quando eu ainda nem sabia o que era um JOIN.
Até…
