Texto de: Lucas Galdino
Introdução
Provavelmente quem é experiente e trabalha com projetos maiores já deve ter uma noção maior sobre a organização que existe utilizando as bases dos grandes padrões de projeto. Entretanto, para aqueles que continuam dando os primeiros passos na jornada da programação, se preocupar em utilizar os padrões de projeto pode se tornar um tipo de exagero, especialmente se a pessoa estiver envolvida com projetos pequenos. Por isso, trarei algumas dicas mais simples e diretas sobre organização de um projeto que podem ajudar no início dessa jornada.
Nomenclatura e os Cases
A nomenclatura de elementos de um projeto é um tema muito importante, e é preciso tomar alguns cuidados na hora de definir os nomes de variáveis e pastas, por exemplo. O primeiro cuidado que precisamos ter é com relação a espaços e caracteres especiais, que devem ser evitados, já que estes tipos de caracteres podem não ser reconhecidos corretamente pela ferramenta que você está utilizando para rodar o código, causando problemas. A língua usada para escrever os nomes também é algo a se prestar atenção e esta dependerá apenas de uma decisão do time e do projeto em questão. Não tem um certo ou errado aqui, o correto é manter a padronização definida pelo time no projeto inteiro.
Dito isso, você também deve nomear os elementos do seu projeto de forma clara, direta e resumida. Esse nome deve fazer sentido com o conteúdo do elemento e o contexto onde ele está inserido. É interessante que os nomes deem uma ideia bem clara do que aquele arquivo ou pasta contém, ou de qual função aquele código possui.
Um arquivo chamado testes.js é simples, mas não é claro, já que só pelo nome não é possível sabermos o que ele realmente contém, ou a função do seu conteúdo. Se trocarmos o nome para algo como testesdousuario.js já fica mais fácil de entender qual a real função desse arquivo, mas mesmo assim, temos uma pequena dificuldade na legibilidade.
Para tornar o nome do arquivo mais legível, podemos usar os cases, que são convenções de nomenclatura utilizados abertamente e em larga escala no mundo da programação, em basicamente todo projeto. Os cases tornam o nome de elementos do projeto mais legíveis e podem ser usados para escrever o nome de um arquivo, o nome de uma pasta ou até mesmo uma variável no próprio código. Conheceremos alguns dos cases a seguir.
snake_case
No snake case utilizamos o símbolo underline para fazer a separação das palavras e iniciamos as palavras com letras minúsculas. Alguns exemplos:
- nome_de_arquivo.js
- nome_de_pasta
- var nome_da_variavel = valor;
camelCase
Já dentro do camel case todas as palavras são escritas juntas, porém em todas as palavras após a primeira, devemos iniciar com letras maiúsculas, seguem os exemplos:
- nomeDeArquivo.js
- nomeDePasta
- var nomeDaVariavel = valor;
PascalCase
O pascal case é similar com ao camel case, porém, aqui a primeira palavra é incluída na regra da primeira letra maiúscula. Dessa forma:
- NomeDeArquivo.js
- NomeDePasta
- var NomeDaVariavel = valor;
kebab-case
O kebab case lembra o snake case, porém, trocamos o underline pelo símbolo de menos, o tracinho (-). Aqui alguns exemplos:
- nome-de-arquivo.js
- nome-de-pasta
- var nome-da-variavel = valor;
Organização
Você pode usar os cases para qualquer coisa dentro do seu projeto, mas é importante salientar aqui que algumas linguagens possuem convenções internas próprias, então também devemos ficar atentos a isso. No JavaScript, por exemplo, é uma convenção de que classes iniciem seus nomes com letras maiúsculas e que variáveis iniciem com letras minúsculas.
Agora deixando de lado um pouco a questão dos nomes, falaremos sobre o conteúdo desses elementos. Para organizar o projeto de forma coesa é interessante separar os arquivos em pastas que contenham um mesmo contexto. Por exemplo, caso seu projeto tenha arquivos que trabalhem com Usuário e outros que trabalham com Financeiro não é interessante que você guarde esses arquivos na mesma pasta, é interessante que você os separe a partir do contexto de cada um. Dessa forma podemos ter diversas pastas no projeto que organizam os arquivos pelo seu contexto, uma pasta chamada pages, screens, telas ou paginas para guardar arquivos relacionados às páginas do projeto, uma pasta data ou dados parar guardar os arquivos relacionados a banco de dados e por aí vai.
No código a ideia é a mesma, não é interessante ter dentro do mesmo arquivo de código trechos de código que tenham funções completamente diferentes em relação ao contexto. Como, por exemplo, deixar uma função de cadastro do usuário e uma função de calcular o preço de um produto dentro do mesmo arquivo. Em muitos casos é mais interessante termos mais arquivos para beneficiar a legibilidade do projeto do que tentar deixar o projeto o mais enxuto e resumido possível e acabar causando esses conflitos de contexto dentro dos mesmos arquivos.
Conclusão
Como citado lá no início deste artigo, existem padrões de projetos mais robustos e voltados para organizar os projetos de forma mais eficaz, porém são muitos e preparados para projetos mais robustos. O foco aqui foi trazer uma visão mais básica e voltada para projetos menores e mais simples. Pois é importante que todos comecem a ter a boa prática de organizar os projetos desde cedo, mesmo não sendo o momento de aprender sobre padrões de projeto ainda.
