Boas práticas que fazem a diferença #2 📝
Tags: braziliandevs, beginners, programming, productivity
Published: 2024-06-15 04:55:19

Esse é o segundo post de uma série sobre boas práticas que eu aprendi durante a minha jornada, tanto no trabalho e processos seletivos, quanto na faculdade e projetos pessoais ou de comunidades.

Confira o primeiro post [clicando aqui](https://dev.to/superp0sit1on/pequenas-boas-praticas-que-fazem-a-diferenca-parte-1-24ka).

## Sumário

- [1. Git Flow](#1-git-flow)
- [2. Segredos](#2-segredos)
- [3. Organização de um projeto](#3-organização-de-um-projeto)

## 1. Git Flow

Esse é um assunto um tanto extenso, portanto, vamos tentar resumir os seus principais pontos, mas recomendo fortemente buscar se aprofundar neste tópico posteriormente, assim como todos os outros tópicos dos quais eu lhes apresentei.

**Git Flow** é um modelo de fluxo de trabalho para repositórios **Git**[^1], sendo um grande aliado em projetos de médio ou grande porte, ou mesmo em projetos menores com mais de uma pessoa trabalhando, pois nos ajuda a organizar e padronizar a estrutura do nosso repositório/projeto Git.

Para se adotar o Git Flow, você deve possuir ao menos duas das primeiras branches principais abaixo:

- **`main`**[^2]: branch principal contendo todas as alterações estáveis e previamente aprovadas em outras branches.
- **`develop`**[^2]: branch intermediária onde as alterações são realizadas (normalmente apenas em projetos de pequeno porte) ou mescladas (merge) de outras branches temporárias;
- **`hom`**: branch intermediária com fins de homologação das alterações, antes de enviá-las para a `main`;
- **`stage`**: branch intermediária menos comum, também com fins de homologação, porém, conectada a algum ambiente com configurações similares as do ambiente de produção, por exemplo, em casos de grandes aplicações webs comerciais.

E por fim, as branches temporárias, onde as alterações são normalmente desenvolvidas:

- **`feature/nome-da-feature`**: branches onde são desenvolvidas determinadas features para então serem mescladas a branch `develop`.
- **`fix/nome-da-correção`**: branches onde são desenvolvidas correções para bugs encontrados ou reportados pelas pessoas usuárias.
- **`hotfix/nome-da-correção`**: branches onde são desenvolvidas correções urgentes, das quais normalmente não é possível aguardar todo o fluxo de entrega de uma nova versão.
- **`release/nome-ou-versão-da-release`**: branches onde mesclamos todas as alterações planejadas para uma determinada versão do projeto, normalmente utilizada em conjunto com alguma automação de integração contínua.

Para concluir, no Git Flow nós realizamos os trabalhos nas branches temporárias e depois mesclamos tudo na branch `develop`, opcionalmente mesclando para fins de testes e aprovações nas branches `stage`, `hom`, ou mesmo na própria branch `develop`, e por fim, mesclando na branch `main`, disponibilizando as alterações em produção.

Outro ponto interessante do Git Flow, é que ele nos ajuda a melhor estruturar também nossas ferramentas de **integração contínua (CI)**, porém, não é recomendado para casos de **entrega contínua (CD)**, pois iria gerar a necessidade de branches de longa duração ou mesmo permanente (além das 2 ou 3 principais).

[^1]: É muito comum vermos uma confusão com relação ao Git, GitHub, GitLab, etc. Mas é importante lembrar, que o Git é a ferramenta de versionamento, enquanto o GitHub e afins, são plataformas de hospedagem e gerenciamento seguro em nuvem desses repositórios/projetos Git. 
[^2]: Hoje em dia não se utiliza mais do padrão de nomenclaturas `master`, `slave`, entre outras, por conta da sua conotação racista e em apoio ao movimento "Black Lives Matter", começando com o GitHub, e por fim outras empresas adotando o novo padrão pelos mesmos motivos.

## 2. Segredos

_Secrets_ em inglês, são todos os dados sigilosos utilizados nas aplicações que não devem ser publicamente acessíveis, como por exemplo, senhas, chaves de APIs, tokens, etc.

Mas como escondê-los em nossos projetos? Normalmente fazemos uso de variáveis de ambiente (_environment variables_, ou apenas _env vars_) e ferramentas especializadas em gestão e hospedagem segura de segredos como a [AWS Secrets Manager](https://aws.amazon.com/pt/secrets-manager).

Os próprios sistemas operacionais possuem gerenciadores de variáveis de ambiente, mas é comum vermos também a utilização de arquivos como o `.env`[^3] para facilitar a utilização de segredos específicos de projetos:

```env
DB_HOST=172.0.0.1
DB_PORT=5432
DB_USER=admin
DB_PASSWORD=123
```

Muitas tecnologias possuem nativamente funções ou métodos para a leitura e manipulação de variáveis de ambiente, porém, em alguns casos é necessário o uso bibliotecas de terceiros, como era o caso do Node.js, mas hoje a partir da versão 20.6.0, tendo suporte nativo à leitura de arquivos `.env`. Por exemplo, dados o arquivo `.env` acima e o código abaixo:

```javascript
const DB_HOST = process.env.DB_HOST,
      DB_PORT = process.env.DB_PORT,
      DB_USER = process.env.DB_USER,
      DB_PASSWORD = process.env.DB_PASSWORD;

...
```

Bastaria iniciar o nosso projeto com os seguintes argumentos no terminal, para que a aplicação Node.js, executasse carregando os segredos contidos no arquivo `.env`:

```shell
node --env-file=.env nome_do_arquivo.js
```

[^3]: Arquivos que contenham segredos como o `.env`, por sua natureza devem ser incluídos no arquivo `.gitignore` em caso de envio para repositórios remotos, do contrário qualquer pessoa com acesso a esses repositórios teriam acesso a eles, mesmo casos elas não possuíssem autorização para os utilizá-los.

## 3. Organização de um projeto

Como já vimos no [primeiro post](https://dev.to/superp0sit1on/pequenas-boas-praticas-que-fazem-a-diferenca-parte-1-24ka), cada pessoa, tecnologia, time, ou empresa podem possuir padrões/convenções de organização de projetos, pastas, arquivos, etc.

É importante conhecer bem os padrões mais utilizadas na área ou da tecnologia da qual você utiliza, sendo eles normalmente descritos em artigos ou mesmo nas próprias documentações, como por exemplo nas seguintes documentações para projetos [Next.js](https://nextjs.org/docs/getting-started/project-structure) ou [FastAPI](https://fastapi.tiangolo.com/tutorial/bigger-applications).

---

Por hoje é isso, espero que gostem e para qualquer feedback ou discussão construtiva, nos vemos nas redes sociais e aqui nos comentários! 🎉