|
|
|
| [Home](home) | [Convenções e Diretrizes](Convenções e Diretrizes) |
|
|
|
|
| :--------------: | :---------------------------: |
|
|
|
|
|
|
|
|
Este documento define as regras e padrões de desenvolvimento a serem seguidos por toda a equipe ao longo do projeto.
|
|
|
|
|
|
|
|
### 📌 Regras Gerais ###
|
|
|
|
✅ Código em inglês (nomes de variáveis, funções, arquivos e comentários).
|
|
|
|
|
|
|
|
✅ Utilize nomes descritivos e claros.
|
|
|
|
|
|
|
|
✅ Evite abreviações, a menos que sejam amplamente compreendidas (ex: ID, URL, API).
|
|
|
|
|
|
|
|
✅ Todo novo código deve ser revisado por pelo menos 1 AGES III ou IV antes do merge.
|
|
|
|
|
|
|
|
### 🌿 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
|
|
|
|
|
|
|
|
### 📂 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:
|
|
|
|
|
|
|
|
**main**
|
|
|
|
- Armazena somente código pronto para produção.
|
|
|
|
- Usado para marcar versões estáveis e lançamentos oficiais.
|
|
|
|
|
|
|
|
**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.
|
|
|
|
|
|
|
|
**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)
|
|
|
|
|
|
|
|
**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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### ✅ 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
|
|
|
|
|
|
|
|
### 🚀 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.
|
|
|
|
|
|
|
|
### 🧪 Testes Unitários
|
|
|
|
#### Ferramentas utilizadas
|
|
|
|
- Frontend: Jest + React Testing Library
|
|
|
|
- Backend: Pytest
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
### 📝 Nomenclaturas e Organização de arquivos
|
|
|
|
- Para arquivos, pastas, variáveis, funções, componentes, etc, usar `camelCase`.
|
|
|
|
- Um componente deve ter sua própria pasta com seus arquivos `index.tsx`, `styles.tsx`, `test.tsx`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
