02 ‐ Padrões de Projeto da Equipe

2.1 - Padrões de Projeto da Equipe

Nesta seção serão abordados os parâmetros e regras de desenvolvimento de projeto da equipe. A grosso modo, será explicado como a equipe se organizou para desenvolver o produto. Essa seção contará com os seguintes temas:

• Modelo e regras na criação de tasks;
• Regras para Aceitação de tasks;
• Modelo e regras de branch;
• Modelo e regras de commits;
• Modelo e regras de pull-request;
• Regras de review de pull-request;
• Regras de teste de código;

2.2 - Regras na criação de tasks

A fim de tornar mais dinâmico e eficiente o desenvolvimento, criamos este "padrão de tasks", seu objetivo é servir como um modelo e explanar o porque desse modelo. Primeiramente é válido deixar explicito que a equipe optou por gerenciar as tasks na plataforma do Github, na aba "Projects", logo, tanto regra quanto modelo q serão apresentados, são baseados nesse cotexto.

O modelo é o seguinte:

nome do card - vertente 
dificuldade - prioridade


### **_Oque fazer_**:
inserir descrição do que se deve fazer
### **_Restrições_**: 
inserir restrições (caso haja)
### **_Falha_**: 
inserir falhas possíveis/comuns que devem ser evitadas e como resolve-las (o que o sistema fará caso elas aconteçam).
### **_Conteúdo_**: 
conteúdo a ser desenvolvido com este card, pode incluir o conteúdo que precisa ser visto ou acessado.

--------------------------------------------------------------------------------------------------------------------------------------------

### **_Aceitação_**:
- [ ] Inserir um parametro de aceitação para que a task seja dada como concluída e o pull-request seja feito
caso hajam casos de falhas eles precisam passar pela aceitação

--------------------------------------------------------------------------------------------------------------------------------------------

### **_Apoio_**:
qualquer material suplementar, que vá ajudar etc.

data inicio - data conclusão

Ver Exemplo

Este é um exemplo de como deve ficar o card ao ser aberto

• nome do card: É o nome da tarefa, precisa ser o mais simples possível;
• vertente: Front ou Back;
• dificuldade: o quão difícil é para a equipe de modo geral, realizar aquela tarefa;
• prioridade: o quão urgente é aquela tarefa?
• descrição: é a abordagem das instruções da tarefa, como fazer, atenções, tudo que envolve o processo dessa tarefa deve ser explicado;
• aceitação: quando a tarefa pode ser dada como concluída e abrir o pull-request?
• data inicio e data coclusão: o encarregado da tarefa deve inserir estes valores, quando começar e quando terminar a tarefa;

2.4 Modelo e regras na criação de branches

Para uma melhor rastreabilidade e análise das tasks realizadas, foi definido um padrão ao criar novas branches, as mesmas levam o tipo, o título, e o id da task que está no scrum board.

O padrão segue o seguinte modelo:

id_da_task-tag_do_tipo_da_branch/descricao

Segue abaixo as tags e seus respectivos tipos de branch:

TAG	TIPO DE BRANCH
func	funcionalidade
corr	correção
refa	refatoração
perf	performance
mant	manutenção
oper	CI, integração, actions e deploy

Note

É possível que o padrão de branchs mude, caso haja necessidade. Se isso acontecer, é de suma importância que o modelo e a tabela sejam atualizados.

Exemplo

No Scrum Board existe a task 'swagger' de id 1. Portanto, a nomeação da branch deve seguir próxima do seguinte modelo:

1-func/swagger

Warning

Evite caracteres especiais e acentuações nas branches.

2.5 Modelo e regras na criação de commits

Para melhor organização do time, foi criado um padrão que deve ser seguido na criação de commits. Esse padrão tem como objetivo facilitar o entendimento das alterações feitas nos trechos de código, promovendo agilidade na rastreabilidade de possíveis erros durante o desenvolvimento do projeto.

O padrão segue o seguinte modelo:

tag_do_tipo_do_commit: descricao_da_alteracao_do_commit

Segue abaixo as tags e seus respectivos tipos de commit:

TAG	TIPO DE COMMIT
func	funcionalidade
corr	correção
refa	refatoração
perf	performance
mant	manutenção
oper	CI, integração, actions e deploy

Note

É possível que o padrão de commits mude, caso haja necessidade. Se isso acontecer, é de suma importância que o modelo e a tabela sejam atualizados.

Exemplo

Realizei uma alteração no código-fonte que adiciona o endpoint de login à aplicação. Portanto, o commit deve seguir o seguinte modelo:

func: adicionar o endpoint de login

Warning

Preze pelo espaço entre os dois pontos e a descrição da alteração do commit. Além disso, evite caracteres especiais e acentuações nos commits.

2.6 Padrão de documentação de endpoints para o Swagger

Todo o endpoint do API deve ser documentado através do @extend_schema usado pela biblioteca drf_spectacular para a criação do Schema utilizado no Swagger.

Sempre acima da função de cada método do respectivo endpoint deve ser codificado um @extend_schema contendo parameters (se necessário), request (se necessário) e response com os status dos possíveis retornos.

Exemplo:

from .models import User
from .serializers import UserSerializer
from rest_framework.views import APIView
from rest_framework.response import Response
from rest_framework import status
from drf_spectacular.utils import extend_schema

class UserViewSet(APIView)
@extend_schema(
    responses={
        200: UserSerializer(many=True),
        400: OpenApiResponse(
            description="Bad Request",
            examples={
                "application/json": {
                    "message": "Erro ao listar usuários"
                }
            }
        )
    }
)
def get(self, request, format=None):
    try:
        users = User.objects.all()
        serializer = UserSerializer(users, many=True)
        return Response(serializer, status=status.HTTP_200_OK)
    except:
        return Response({'message': 'Erro ao listar usuários'}, status=status.HTTP_400_BAD_REQUEST)