Diretrizes de Desenvolvimento do Projeto

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.

1. Padrões Gerais

• 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.

2. Estratégia de Controle de Versão (Git)

Este projeto utiliza o modelo de ramificação GitFlow para fornecer uma estrutura robusta para o gerenciamento do desenvolvimento.

2.1. GitFlow

O modelo define cinco tipos de branches distintas:

• main

  • Contém exclusivamente código pronto para produção.
  • Esta branch contém lançamentos de versões oficiais e estáveis.

• develop

  • 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.

• <task_id>/<task_description>

  • 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.

• fix/*

  • 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. 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. Enquanto no frontend trabalharemos com JestJS

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.