A importância de um bom planejamento e como isso reflete na qualidade do código!

Lá está você, programador iniciante, ponderando sobre qual seria o seu primeiro projeto pessoal, você no momento não busca enriquecer financeiramente, mas sim criar algo que funcione e seja útil, então, como todo marinheiro de primeira viagem, você imediatamente abre o vs code, apenas com a ideia na cabeça, e começa a escrever o html, o css, as integrações... Nossa, incrível como você em pouco tempo já escreveu tanto! Mas infelizmente, depois que você foi dormir e no dia seguinte iria continuar a produção... você não entende nada do que está acontecendo.

Uma breve e talvez inútil história, mas que serviu apenas de prólogo para a mensagem que eu quero passar, muitas vezes a gente se empolga com uma ideia e simplesmente a começa instantaneamente e... ok, claro, temos que colocar aquilo que vem a nossa cabeça em prática, porém quando se trata de um projeto (e quando eu digo projeto, falo daqueles que você quer realmente que funcione, e não apenas uma prática momentânea que talvez você nem termine) o buraco é mais embaixo, isso porque você tem que ter uma visão ampla e profissional daquilo que está fazendo. Coisas como definir um flow do usuário, estabelecer um modelo de UI padronizado (e não to falando de bibliotecas não, eu digo sobre você padronizar o seu site, seja em lógica de cores, espaçamentos e responsividade) e definir como os dados serão lidos e enviados são fundamentais para que se tenha uma escrita de código automática, sem precisar pensar muito no "como fazer" ou em "o que vou fazer".

Tá, mas o que isso realmente significa?

Se temos o design pre-estabelecido, a lógica definida e simplesmente tudo aquilo que você já poderia ter planejado você planejou, você só precisa escrever o código, sem pensar demais. E eu te garanto que você deixando claro aquilo que precisa fazer, aqueles momentos em que você fica olhando para o código na busca de uma solução por horas acontecerão com muito menos frequência.

E outra, mesmo que o projeto seja pequeno, se organize antes, é uma boa prática muito bem acolhida e além de te deixar mais acostumado com a ideia de organização, evitará possíveis frustrações também.

E como seria fazer um bom planejamento?

Se prapare para a surra de conhecimento

Punch number one: reconheça suas ferramentas, como você quer fazer teu projeto?

a minha stack é clássica e normalmente sempre fico nesse grupo: HTML, CSS, JS e PHP. Sou feliz assim e tudo aquilo que almejo produzir eu tento alinhar com o que as tecnologias usadas permitem. De nada adianta querer fazer um SAAS de IA com PHP, misericórdia né. Se eu precisar de alguma coisa extra eu perceberei durante o planejamento e irei incluir na stack, mas a minha base é essa, encontre a sua e adapte-a de acordo com aquilo que deseja construir.

Punch number two: Qual o objetivo do seu projeto e quais "soluções secundárias" ele irá oferecer? Praticamente um momento de reflexão de ideias e filtragem daquilo que realmente faz sentido naquilo que você quer aplicar.

Esse tipo de pergunta você já deve ter visto em trocentos tutoriais, mas entenda que aqui eu não to falando para você olha pro céu e pensar "quero fazer um site de nutrição", não krl, to falando pra vc pegar um papel, uma caneta, e escrever: "criador de plano de dieta com alto grau de personalização" e pronto, a partir dali você começa o seu brainstorming, mas é necessário que você defina o core do seu projeto, se não vira bagunça.

Punch number three: Essa daqui é mais importante para copy e marketing, mas já é interessante que você deixe claro qual problema da sociedade o seu produto resolve e quem tem esses problemas?

Normalmente isso se remete à origem da ideia do seu projeto, recentemente aqui no TabNews apareceu alguém buscando desenvolvedores para fazer um site junto com ele. Pô, o cara tinha um problema que é a dificuldade de encontrar pessoas que estariam dispostas a fazerem um projeto juntas, então porque não fazer um site que junta essas pessoas. Percebe como a faísca do problema gera o objetivo do projeto?

Você poderia tomar esses três socos na sequência inversa que ainda assim iria fazer total sentido.

A partir daqui você já tem a ideia do que você quer fazer e aquilo que você tem que fazer (principalmente se separar as funcionalidades do MVP), porém o planejamento não acabou.

1. Defina o flow do usuário
   Aqui eu sou suspeito a falar porque digamos que primeiro eu faço o site no papel e depois eu passo pro código, então eu faço toda a trajetória do usuário, por onde ele passa, faço também uma simulação do meu produto, o que ele precisa clicar para acontecer x coisa, e aqui você já pode fazer pesquisas da tecnologia que você definiu na stack, se eu defini que ao clicar em um elemento de classe --pocpoc vai rolar um drag and drop com física e se estou usando CSS e JS, eu já marco um asterístico de pesquisa, pois eu tenho que saber se é possível fazer aquilo que eu quero com CSS e JS, ou se já existe uma biblioteca que permita isso, enfim, aqui provavelmente será a fase mais trabalhosa do seu projeto, mas você terá ele pronto no papel e poderá ver possíveis erros de lógica ou incapacidade da tecnologia antes de ter dor de cabeça programando.

2. Hora do design
   Abraços ao figma, aqui é interessante fazer o protótipo visual, estabelecer os padrões e já imaginar na responsividade.

3. A lógica
   Reveja o flow e olhe especificamente a parte do backend, como serão definidas as tabelas da minha bd? Haverá compressão de imagem? Farei de forma manual? Automática? Como farei?
   Também tem as respostas a erros, o que acontece se tal erro acontecer? e outro? como faço para otimizar o upload do video?
   São trocentas perguntas, mas é importante já deixar definido como os dados serão lidos e enviados, além de já deixar registrado também as funções que você vai precisar.

Por fim, acredito que definir uma arquitetura e um padrão de nomenclatura, por mais que você não goste, também é muito importante para você não ficar perdido depois (um salve para a modularidade).

Entre design ou lógica fica a seu critério decidir qual você realizará primeiro, nenhum influencia o outro (eu acho).

Ah e é legal sempre quebrar os problemas nas menores particulas possíveis e se planejar a partir disso, no habitat do design tem SEO, Copy, Branding... tudo isso faz parte do processo.

Por muito eu achava que era trabalheira demais e que era apenas um profissionalismo forçado, até eu colocar a mão na massa e reescrever o mesmo código várias vezes por falta de organização ou clareza de ideias.

Enfim, espero que tenha ajudado bastante e deixo aqui aberto a discussões: Como vocês se planejam para os trabalhos de vocês?

Ass.: j_lucas_hoff Ω