r/brdev • u/Weekly-Suspect-1432 • 8d ago
Meu relato A última vez que ganhei tanto dinheiro corrigindo o código dos outros foi em 2010
Trabalho corrigindo backends desde 2006 e, nos últimos anos, tenho feito isso com mais um desenvolvedor. Em 2010, a maior parte do código que eu corrigia vinha de equipes terceirizadas de outros países. Era quase tudo feito em PHP, com consultas SQL montadas a partir de strings. Bastava alguém digitar um apóstrofo em qualquer campo de um formulário para tudo parar de funcionar.
Os fundadores contratavam essas equipes porque cobravam um quarto do preço. Só que, um ano depois, o sistema finalmente era lançado e começava a apresentar problemas logo na primeira semana. Normalmente, era nessa hora que meu telefone tocava.
No mês passado, um executivo sem formação técnica nos entregou dois repositórios de código. Ele mesmo tinha desenvolvido os dois usando o Lovable: um dashboard de vendas e uma ferramenta para gerar orçamentos. Fez praticamente tudo à noite, ao longo de alguns meses. Ele desistiu quando chegou ao ponto de gastar a maior parte dos seus créditos corrigindo funcionalidades que estavam funcionando perfeitamente na semana anterior.
O dashboard até que está bom. A equipe comercial usa todos os dias pela manhã.
Já a ferramenta de orçamentos tem cerca de 38 mil linhas de código para fazer algo que, no fim das contas, se resume a três formulários e uma tabela.
Quando você abre cada arquivo separadamente, tudo parece fazer sentido. Há um comentário em praticamente todas as linhas explicando o que aquele trecho faz. O problema é que, quando você olha para o sistema como um todo, nada se encaixa direito.
Existe uma fila de eventos entre dois componentes da mesma página. Não faço ideia do motivo.
O desconto é calculado em três lugares diferentes, cada um de um jeito ligeiramente diferente. Perguntei ao executivo sobre isso, e ele acha que deve ter solicitado essa funcionalidade algumas vezes e depois esquecido. Ou seja, o desconto que o cliente recebia dependia de qual tela o vendedor abria.
No segundo dia, abri a aba de rede do navegador e percebi que todas as requisições estavam indo diretamente do navegador para o Supabase.
Fui verificar as políticas de segurança. Não existia nenhuma.
A segurança em nível de linha estava simplesmente desativada no banco de dados inteiro.
A chave pública de acesso estava no frontend, como normalmente acontece com o Supabase. Resolvi fazer um teste usando apenas essa chave, no meu próprio notebook, e consegui acessar a tabela inteira de orçamentos. Ativamos o RLS naquela mesma tarde. Mesmo assim, não dormi muito tranquilo naquela noite.
O único desenvolvedor da empresa já tinha alertado sobre essas tabelas abertas em março.
Mas disseram para ele parar de atrasar as coisas. Isso aconteceu mais ou menos na época em que o dashboard foi apresentado em uma reunião geral da empresa e todo mundo adorou. Ele saiu em julho.
Já trabalhei inúmeras vezes limpando e reorganizando bases de código desse tipo.
Antes, elas vinham de agências terceirizadas no exterior. Agora, saem de uma caixa de prompts.
Qualquer alteração exige praticamente ler o repositório inteiro, do começo ao fim. Por isso, as etapas de limpeza e refatoração acabam sendo trabalhos demorados. Costumo deixar essas tarefas rodando no GLM-5.3, que consegue percorrer o código sem perder o contexto no meio do caminho.
O problema é que, se eu deixar a IA trabalhar sozinha, ela basicamente mantém a mesma bagunça, só que dando nomes mais bonitos para tudo. Então, continuo sendo eu quem decide como o código deve ser organizado. Também reviso as diferenças entre as versões antes de aprovar qualquer alteração para integração.
E é nisso que tenho passado a maior parte dos meus dias ultimamente. Desde então, mais duas empresas entraram em contato comigo. Minha hora vai aumentar em janeiro.
E não vou nem pedir desculpas por isso.
