|
|
|
| [Home](home) | [Convenções e Diretrizes](Convenções e Diretrizes) | [Tecnologias](Tecnologias) | [Banco de dados](Banco de Dados) |
|
|
|
|
| --- | --- | --- | --- |
|
|
|
|
| [Início](https://www.google.com/search?q=home) | [Diretrizes](https://www.google.com/search?q=diretrizes) | [Tecnologias](https://www.google.com/search?q=tecnologias) | [Banco de Dados](https://www.google.com/search?q=banco-de-dados) |
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
Este documento define as regras e padrões de desenvolvimento a serem seguidos por toda a equipe ao longo do projeto.
|
|
|
|
# Diretrizes de Desenvolvimento do Projeto
|
|
|
|
|
|
|
|
### 📌 Regras Gerais ###
|
|
|
|
✅ Código em inglês (nomes de variáveis, funções, arquivos e comentários).
|
|
|
|
Este documento estabelece os padrões, convenções e diretrizes oficiais de desenvolvimento para este projeto. A adesão a estas regras é obrigatória para garantir a qualidade do código, a manutenibilidade e a colaboração eficaz da equipe.
|
|
|
|
|
|
|
|
✅ Utilize nomes descritivos e claros.
|
|
|
|
|
|
|
|
✅ Evite abreviações, a menos que sejam amplamente compreendidas (ex: ID, URL, API).
|
|
|
|
## 1. Padrões Gerais
|
|
|
|
|
|
|
|
✅ Todo novo código deve ser revisado por pelo menos 1 AGES III ou IV antes do merge.
|
|
|
|
* Todo o código, incluindo nomes de variáveis, funções, arquivos e comentários, deve ser escrito em inglês.
|
|
|
|
* Utilize nomes descritivos para todos os identificadores.
|
|
|
|
* Evite abreviações, a menos que representem termos técnicos amplamente compreendidos (ex: ID, URL, API, HTTP).
|
|
|
|
* Todo código exige a revisão e aprovação obrigatória de, no mínimo, um desenvolvedor AGES III ou IV antes de ser mesclado.
|
|
|
|
|
|
|
|
### 🌿 Convenção de Nomes de Branches
|
|
|
|
Use o padrão abaixo:
|
|
|
|
- id-ticket/descrição-curta
|
|
|
|
- 142/login-com-jwt
|
|
|
|
- 159/ajuste-layout-grafo
|
|
|
|
- 201/exportacao-csv
|
|
|
|
## 2. Estratégia de Controle de Versão (Git)
|
|
|
|
|
|
|
|
### 📂 Estratégia de Ramificação
|
|
|
|
Adotaremos a estratégia de GitFlow para este projeto, este modelo define cinco tipos principais de branches, cada um com propósito específico dentro do ciclo de desenvolvimento:
|
|
|
|
Este projeto utiliza o modelo de ramificação [GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) para fornecer uma estrutura robusta para o gerenciamento do desenvolvimento.
|
|
|
|
|
|
|
|
**main**
|
|
|
|
- Armazena somente código pronto para produção.
|
|
|
|
- Usado para marcar versões estáveis e lançamentos oficiais.
|
|
|
|
#### 2.1. GitFlow
|
|
|
|
|
|
|
|
**develop**
|
|
|
|
- Base para integração de novas funcionalidades.
|
|
|
|
- Contém código pré-produção; serve como fonte para criação de branches de feature.
|
|
|
|
|
|
|
|
|
|
|
|
**feature/***
|
|
|
|
- Criadas a partir de develop para desenvolver novas funcionalidades.
|
|
|
|
- Após conclusão e revisão, são mescladas novamente em develop.
|
|
|
|
O modelo define cinco tipos de branches distintas:
|
|
|
|
|
|
|
|
**release/***
|
|
|
|
- Criadas a partir de develop quando o conjunto de funcionalidades está pronto para lançamentos.
|
|
|
|
- Recebem apenas correções de bugs antes da entrega final.
|
|
|
|
- Após estabilização, são mescladas em main (para produção) e develop (para sincronizar correções)
|
|
|
|
* `main`
|
|
|
|
|
|
|
|
**hotfix/***
|
|
|
|
- Criadas a partir de main para corrigir problemas em produção com urgência.
|
|
|
|
- Após correção, devem ser mescladas tanto em main quanto em develop para garantir que os ajustes sejam refletidos no fluxo de desenvolvimento
|
|
|
|
* Contém exclusivamente código pronto para produção.
|
|
|
|
* Esta branch contém lançamentos de versões oficiais e estáveis.
|
|
|
|
|
|
|
|
|
|
|
|
* `develop`
|
|
|
|
|
|
|
|
### ✅ Convenção de Mensagens de Commit
|
|
|
|
Use o padrão abaixo:
|
|
|
|
- tipo(escopo): descrição curta
|
|
|
|
- feat(auth): implementa fluxo de login com JWT
|
|
|
|
- fix(graph): corrige bug no posicionamento de nós
|
|
|
|
- docs(readme): atualiza instruções de setup
|
|
|
|
* Serve como a branch principal de integração para novas funcionalidades.
|
|
|
|
* Representa o código de pré-produção e é a origem para todas as branches de funcionalidades.
|
|
|
|
|
|
|
|
### 🚀 Template de Merge Request (MR)
|
|
|
|
Ao criar um novo MR, terá um template a ser preenchido com as informações sobre o que está sendo adicionado ao código.
|
|
|
|
* `<task_id>/<task_description>`
|
|
|
|
|
|
|
|
### 🧪 Testes Unitários
|
|
|
|
#### Ferramentas utilizadas
|
|
|
|
- Frontend: Jest + React Testing Library
|
|
|
|
- Backend: Pytest
|
|
|
|
* Criadas a partir da `develop` para a implementação de novas funcionalidades.
|
|
|
|
* Após a conclusão e revisão, são mescladas de volta na `develop`.
|
|
|
|
|
|
|
|
Atividades de desenvolvimento também incluem testes unitários, os quais devem ser claros, legíveis e descritivos, além de cobrir casos positivos e negativos.
|
|
|
|
* `fix/*`
|
|
|
|
|
|
|
|
### 📝 Nomenclaturas e Organização de arquivos
|
|
|
|
- Para arquivos, pastas, variáveis, funções, componentes, etc, usar `camelCase` no **frontend** e `snake_case` no **backend**.
|
|
|
|
- Um componente deve ter sua própria pasta com seus arquivos `index.tsx`, `styles.tsx`, `test.tsx`.
|
|
|
|
* Criadas a partir da `develop` para corrigir bugs críticos no ambiente de produção.
|
|
|
|
* Após a correção ser implementada, a branch deve ser mesclada de volta tanto na `main` quanto na `develop`.
|
|
|
|
|
|
|
|
### 2.2. Convenção para Nomes de Branches
|
|
|
|
|
|
|
|
As branches de funcionalidades devem seguir o formato: `<id-do-ticket>/<descricao-curta>`. Tal como os exemplos abaixo.
|
|
|
|
```
|
|
|
|
142/login-com-jwt
|
|
|
|
159/ajuste-layout-grafo
|
|
|
|
201/exportacao-csv
|
|
|
|
```
|
|
|
|
|
|
|
|
### 2.3. Convenção para Mensagens de Commit
|
|
|
|
|
|
|
|
As mensagens de commit devem seguir a especificação de [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). Os exemplos abaixo ilustram o formato:
|
|
|
|
```
|
|
|
|
feat(auth): implementa fluxo de login com JWT
|
|
|
|
fix(graph): corrige bug no posicionamento de nós
|
|
|
|
docs(readme): atualiza instruções de setup
|
|
|
|
```
|
|
|
|
|
|
|
|
### 2.4. Processo de Merge Request (MR)
|
|
|
|
|
|
|
|
Todos os Merge Requests devem ser submetidos utilizando o template de MR fornecido. Os campos do template devem ser preenchidos de forma completa para fornecer o contexto necessário aos revisores de código.
|
|
|
|
|
|
|
|
### 3. Estilo de Código e Organização de Arquivos
|
|
|
|
|
|
|
|
O _casing_ para o código do repositório de backend deve ser `snake_case` e deverá ser aplicada regras de _linting_ e com _type hints_ para facilitar entendimento do código.
|
|
|
|
|
|
|
|
Para o repositório frontend, utilizaremos `camelCase` para todos os nomes de arquivos, variáveis e funções. Além disso, os componentes `React` devem ser organizados em suas próprias pastas dedicadas. Cada pasta deve conter, no mínimo, a lógica do componente (`index.tsx`), sua estilização (`styles.tsx`) e seus testes unitários (`test.tsx`).
|
|
|
|
|
|
|
|
## 4. Padrões de Testes
|
|
|
|
|
|
|
|
As ferramentas de teste para o backend será [pytest](https://docs.pytest.org/en/stable/). Enquanto no frontend trabalharemos com [JestJS](https://jestjs.io/)
|
|
|
|
|
|
|
|
O desenvolvimento de testes unitários é _parte obrigatória do processo de implementação de funcionalidades_. Os testes devem ser claros, legíveis e descritivos. A cobertura de testes deve incluir cenários positivos e negativos (_happy path_ e _edge cases_) para garantir a robustez do código. |
|
|
\ No newline at end of file |
