This content originally appeared on DEV Community and was authored by Marcos Gabriel
Quando atingimos um certo nível de domínio em uma linguagem ou framework — aquele momento em que já conseguimos criar aplicações reais, como uma API ou uma landing page — é comum ficarmos empolgados. De repente, queremos construir tudo, aprender o máximo possível e entrar logo no mercado, sendo finalmente pagos para programar. Mas é exatamente nesse ponto que a confusão começa.
Várias vezes me peguei iniciando uma ideia “milionária” que surgiu do nada: um projeto incrível que, na minha cabeça, faria recrutadores disputarem por mim e mostraria ao mundo o meu talento. Em todas essas vezes, desisti nas primeiras duas horas.
Consigo listar projeto por projeto que abandonei logo após implementar um fluxo de usuário, uma autenticação ou até mesmo um simples endpoint. Hoje entendo com clareza qual era o meu maior problema: a falta de planejamento.
Veja bem, o trabalho de um desenvolvedor envolve lógica, compreensão de comportamentos e regras de negócio. Mas, por muito tempo, eu me esquecia de que o desenvolvimento começa antes de qualquer linha de código.
Imagine que você começou sua ideia bilionária e, após os primeiros minutos codando, começa a se questionar: “O que exatamente isso deveria fazer?”. Você seguiu o primeiro impulso, mas logo percebe que, se o usuário seguir um caminho específico, o sistema já não se comporta como deveria. Então, você interrompe o que estava fazendo para pensar no produto. Quando volta ao código, o ritmo já não é o mesmo — e a empolgação de se tornar o novo gênio da computação desaparece.
Brincadeiras à parte, além das questões de produto, eu também travava diante das decisões arquiteturais:
“Uso Clean Architecture ou Onion?”
“Melhor utilizar DTOs _ou _Form Requests?”
“Organizo com Services _ou crio uma camada de _Domínio?”
Essas dúvidas se acumulavam e minavam meu ânimo. No fundo, o problema era sempre o mesmo: planejamento insuficiente.
Antes de começar a codar, desenhe os fluxos da aplicação — pode ser em uma folha de caderno mesmo. Se preferir uma abordagem mais moderna ou ecológica, use ferramentas como o Excalidraw. Utilize notações como BPMN para estruturar os processos e tente antecipar todos os fluxos possíveis. Tudo isso antes de escrever qualquer linha de código.
Escrever código, no geral, não é a parte mais difícil (claro, há cenários complexos e muitas variáveis). Mas escrever sem saber o que escrever torna tudo muito mais complicado. Afinal, você precisa lidar ao mesmo tempo com decisões técnicas e com os detalhes do negócio.
E mais: além de planejar antes de codar, documente sua ideia por partes, como seria feito em um ambiente profissional. Seu projeto não precisa (e nem deve) nascer completo em uma única sprint. Divida os fluxos, descreva o comportamento esperado do sistema, pense desde o início em como os testes seriam feitos.
Porque, se você começar a escrever código sem pensar nisso, tudo poderá ficar tão acoplado que, quando quiser testar algo, os testes unitários parecerão impossíveis. E aí, aquela ideia promissora começa a exigir uma reescrita — e, junto com ela, vem o desânimo.
No fim das contas, tudo que eu compartilhei aqui vem da minha própria experiência. Essas foram as dores que enfrentei quando comecei a fugir dos projetos de curso e tentei colocar minhas ideias em prática. Aprendi, na marra, que planejamento e estrutura são tão importantes quanto o código em si.
This content originally appeared on DEV Community and was authored by Marcos Gabriel