Como Fazer Um Desenvolvimento

O que a maioria não entende sobre desenvolvimento

Desenvolvimento não é escrever código. É tomar decisões sob pressão de informação incompleta e viver com elas por meses depois. A maior parte do trabalho acontece antes do editor abrir, na cabeça de quem precisa saber o que construir e por quê. O código em si é a parte trivial. Quando alguém pergunta como fazer um desenvolvimento, a resposta curta é: você define o problema, escolhe a ferramenta errada com confiança, descobre que estava errado duas semanas depois, e refaz metade do caminho. Isso não é pessimismo, é descrição. O processo funciona assim porque o problema real nunca é claro no início. Se fosse, já teria solução pronta.

como fazer um desenvolvimento de verdade

Comece escrevendo em português claro o que o sistema precisa fazer, não como ele vai funcionar. "O usuário precisa conseguir exportar relatórios em PDF" é diferente de "precisamos usar a biblioteca X com a configuração Y". A primeira frase sobrevive a mudanças de tecnologia. A segunda morre na primeira versão do framework. Aqui vai algo que leva tempo pra entender: escrever menos código geralmente economiza mais tempo do que escrever melhor código. Um colega meu passou três semanas construindo um sistema de filas assíncronas com Redis, retry exponencial e monitoramento para um processo que era executado quatro vezes por mês. Uma função síncrona com um log de erro resolvia. A solução elegante era overhead disfarçado de sofisticação.

O fluxo real funciona mais ou menos assim. Você lê os requisitos e subtraí tudo que não é essencial. Sobrou algo? Tenta resolver com o mínimo possível, mesmo que pareça grosseiro. Só depois de rodando é que identifica os gargalos. Perfilar antes de ter dados é aprofundar no escuro. Um problema concreto que encontrei recentemente envolvia migração de banco. O cliente tinha uma tabela com 14 milhões de linhas e queria mudar o tipo de uma coluna de texto para JSONB sem downtime. A resposta óbvia — criar nova coluna, popular, trocar a referência, dropar a antiga — travava a tabela inteira durante a cópia. O workaround que funcionou foi criar a coluna JSONB em paralelo usando um worker separado, atualizar apenas as linhas que mudavam via trigger DML, e só fazer o swap final quando o atraso ficou dentro de margem aceitável. Leva cerca de 40 minutos a mais do que o método ingênuo, mas não exige janela de manutenção.

Arquitetura e decisões que importam

Escolha de stack é menos sobre tecnologia e mais sobre quem vai manter depois de você. Um sistema construído com Rust é impressionante até o dia em que o próximo desenvolvedor precisa de um patch urgente às 23h e não consegue encontrar ninguém que saiba lidar com o borrowing checker. Python lento mas mantido por três pessoas na equipe é mais produtivo no longo prazo do que Go rápido mantido por você sozinho. Testes automatizados são necessários mas insuficientes. O que distingue um desenvolvimento maduro é a observabilidade. Logs estruturados, métricas de latência por endpoint, e traces distribuídos costumam valer mais do que cobertura de 90%. Você pode ter todos os testes passando e ainda assim perder uma requisição em produção porque o cache de redis retornou um dado obsoleto. Testes não capturam isso.

Aqui está uma verdade contraintuitiva: monólitos bem estruturados superam microsserviços na maioria dos casos até equipe de 15 pessoas no máximo. Cada serviço adicional introduz latência de rede, complexidade de deploy, consistência eventual e custo operacional. Microserviços são uma solução para problemas de organização e escala que a maioria dos times nunca atinge. O tempo que você economiza evitando orchestration é tempo que pode usar em features reais.

Gestão do ciclo de vida

Revisão de código não serve para corrigir bugs. Serve para transmitir conhecimento. Se só uma pessoa entende um módulo, aquele módulo é um risco operacional. Pull requests devem ser pequenos — menos de 400 linhas — porque revisões longas geram fadiga cognitiva e bugs passam despercebidos. Revisores devem focar em lógica de negócio e segurança, não em formatação. Lint resolve formatação. Deployments frequentes e pequenos reduzem risco drasticamente. Desfazer uma mudança de mil linhas é muito mais difícil do que desfazer uma mudança de dez linhas. O conceito de blast radius importa mais do que velocidade de deploy. Cada liberação deve ser algo que você consegue reverter em menos de cinco minutos com confiança.

Documentação técnica sobrevive apenas enquanto quem escreveu ainda está no projeto. Escreva docs funcionais — exemplos de uso, decisões de arquitetura documentadas em ADRs simples, runbooks de recuperação. Documentação que descreve a interface pública é útil. Documentação que replica o código em palavras naturais é ruído.

Falhas comuns e quando desistir

O mayor erro é continuar desenvolvendo algo que já não gera valor. Métricas de progresso como linhas de código, commits por dia ou stories completadas são métricas de vanity. O que importa é se a funcionalidade resolve o problema do usuário final. Às vezes a melhor decisão técnica é cancelar o projeto e reaproveitar o que já existe de outra forma. Technical debt é real mas mal compreendido. Dívida técnica ruim é aquela que cresce sem benefício — código complexo que ninguém entende e ninguém precisa modificar. Dívida técnica boa é quando você escolhe deliberadamente uma solução mais rápida sabendo que vai precisar refatorar depois, porque o timing comercial não permite o ideal. A diferença entre as duas é consciência. Sem consciência, dívida vira pano de fundo permanente.

Ferramentas ajudam mas criam dependência. CI/CD pipelines, containerização, orquestração — tudo é útil até o dia em que quebra e você não sabe o que aconteceu por dentro. Entender pelo menos o básico de rede, sistema operacional e memória é o que separa alguém que opera ferramentas de alguém que resolve problemas. Quando o Kubernetes falha, não adianta ler a documentação. Precisa saber o que estava acontecendo no nó antes do crash. Desenvolvimento é essencialmente engenharia aplicada a problemas que mudam enquanto você os resolve. A habilidade principal não é saber tecnologia, é saber escolher qual tecnologia não usar. O resto é rotina.