Como melhorar seu código (5 passos)

Estava lendo uns artigos na internet e encontrei um bem interessante sobre como melhorar o código, ou melhor, como melhorar a forma como você trabalha enquanto programador. O nome do artigo é "Write Less, Fix Never", que seria algo como "escreva menos, nunca corrija". É um título um pouco sensacionalista, porque óbvio que você sempre vai corrigir bugs, isso nunca vai deixar de acontecer. Mas a ideia central é evitar ao máximo ter que ficar corrigindo.

Não vou reproduzir o artigo inteiro, vou comentar os pontos principais e adicionar minha própria experiência em cima de cada um. E no final vou incluir um quinto ponto que não estava no artigo original.

1. Planeje para 10x

Muita gente, e não só iniciante, comete o erro de planejar um sistema com um nível de complexidade que ele nunca vai precisar.

Imagina que você está criando um sistema para uma academia de bairro, com uns 500 alunos cadastrados. No horário de pico, talvez 50 pessoas acessem o sistema ao mesmo tempo. Não faz sentido nenhum planejar esse sistema para suportar 1 milhão de acessos simultâneos. A complexidade de um sistema para 50 acessos é completamente diferente da complexidade para 1 milhão, porque quando o volume é gigantesco você precisa se preocupar com cache em tudo que for possível, processar a menor quantidade de dados possível, otimizar cada requisição.

Existe um termo em inglês para isso: over engineering. É quando você foca demais na engenharia e cria uma solução complexa demais para um problema pequeno, tipo usar uma bazuca para matar uma formiga.

A regra de ouro é: construa para o que é esperado, não para o que pode um dia acontecer. Se você sabe que vai ter 50 acessos simultâneos, planeje para uns 500. Isso já é uma boa margem sem que o desenvolvimento fique travado tentando prever um cenário que talvez nunca aconteça. Se o crescimento absurdo realmente vier, dá para repensar a arquitetura nesse momento, com o problema real na mão em vez de um problema imaginário.

2. Evite ficar indo e voltando entre tarefas

Um dos piores cenários no dia a dia de programação é terminar uma funcionalidade, começar a próxima e, no meio do caminho, ter que voltar para corrigir um bug na anterior. Isso quebra o fluxo, atrapalha a produtividade e no final do dia a cabeça fica confusa de tanto pular de contexto.

Uma forma de reduzir isso é planejar um pouco mais antes de sair escrevendo código só para "funcionar". Isso não significa cair no ponto anterior e complicar demais, é só não ir com tanta pressa.

Quando você já tem mais experiência, vale investir em testes automatizados: unitários, de integração, end-to-end. A lógica é simples: antes de implementar a funcionalidade, você escreve os testes pensando em tudo que pode dar errado. Um login sem usuário, um e-mail inválido, uma senha vazia, um campo manipulado direto no HTML. No começo todos os testes falham, porque a funcionalidade ainda nem existe. Depois você vai implementando até cada teste passar.

Só o exercício de pensar nesses casos antes de escrever o código já melhora muito a qualidade do que você entrega, e reduz bastante a chance de ter que voltar depois para apagar incêndio.

3. Aja, não reaja

Esse é um erro clássico que já aconteceu comigo: um sistema em produção, funcionando bonito, e em algum momento o usuário passa a fazer upload de imagens que vão sendo salvas direto no disco do servidor. Óbvio que, cedo ou tarde, esse disco vai encher. E quando enche, ninguém mais consegue fazer upload, o problema já chegou até o usuário.

Nesse ponto você está reagindo a um problema que já virou incêndio. O ideal é agir antes disso acontecer. A maioria dos provedores de hospedagem já oferece alertas de uso de disco, memória e processamento. Configurar um aviso para quando o disco chegar em 80% de uso, por exemplo, permite agir enquanto ainda dá tempo de aumentar o espaço, otimizar o armazenamento ou limpar cache antigo, sem que o usuário nem perceba que existiu um problema.

O importante aqui não é a ferramenta de monitoramento em si, é o hábito de colocar avisos que te avisam antes do problema explodir, em vez de descobrir o problema pela reclamação de alguém.

4. Documente suas decisões

Imagina que você, ou alguém do seu time, escolheu usar o Zod em vez do Yup para validação de dados numa funcionalidade específica. Meses depois alguém pergunta por que essa escolha foi feita, e você simplesmente não lembra. Vai ter que inventar uma justificativa ou admitir que não sabe.

A solução é simples: anote as decisões em algum lugar. Não precisa ser nada elaborado, pode ser um bloco de notas, o Notion, um arquivo de texto no próprio repositório. O importante é registrar o que foi decidido e por quê, mesmo que a razão pareça óbvia no momento em que você está decidindo.

Isso facilita demais o trabalho em equipe, principalmente em reuniões de alinhamento, e evita que você perca tempo tentando reconstruir um raciocínio que já fez sentido para você uma vez e que provavelmente vai fazer sentido de novo, se estiver escrito.

5. Use IA como parceira de raciocínio, não como atalho

Esse ponto não estava no artigo original, mas hoje em dia é difícil falar de melhorar como programador sem falar de IA.

O erro mais comum é usar a IA só para gerar código pronto e colar sem entender o que foi gerado. Isso não te torna melhor programador, só te deixa dependente. O uso que realmente melhora seu código é o oposto: usar a IA para revisar decisões, apontar riscos que você não pensou, sugerir abordagens alternativas antes de você escrever a primeira linha.

Antes de implementar algo mais complexo, vale descrever o problema para a IA e pedir para ela apontar os pontos cegos: o que pode dar errado, quais casos de borda você não considerou, se existe uma abordagem mais simples. Depois de implementado, também vale pedir uma revisão crítica do que você fez, não para a IA reescrever tudo, mas para você enxergar problemas que passariam despercebidos.

Isso conecta direto com os pontos anteriores: a IA ajuda a pensar nos casos de erro antes de escrever os testes, ajuda a identificar se você está com over engineering ou o contrário, e até ajuda a documentar as decisões que você tomou, já que muitas vezes a própria conversa com a IA registra o raciocínio por trás de uma escolha. O ganho real não é a velocidade de gerar código, é usar a IA para expor os buracos do seu raciocínio antes que eles virem bugs em produção.

Resumindo

Planeje para o que é esperado, não para hipóteses distantes. Pense nos casos de erro antes de escrever a funcionalidade. Prefira agir com avisos antecipados em vez de reagir a incêndios. Documente por que tomou cada decisão. E use a IA para revisar seu raciocínio, não para substituir ele.

Nenhum desses pontos sozinho resolve tudo, mas juntos fazem uma diferença enorme na quantidade de tempo que você passa corrigindo em vez de construindo.