02 ‐ 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;
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 o que fazer;
**_Restrições_**: inserir restrições, se houver;
**_Falha_**: inserir casos que podem falhar e o que deve acontecer;
**_Conteúdo_**: inserir o conteúdo a ser exibido ou tratado;
link para figma (se for task com vertente do front)
------------------------
aceitação;
------------------------
data inicio - data conclusão
- 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;
exemplo:
| Nome do card | Vertente | Dificuldade | Prioridade | Descrição | Aceitação | Data de Inicio | Data de conclusão |
|---|---|---|---|---|---|---|---|
| Home-page | Front | Facil | Baixa |
Oque fazer: Criar uma tela, em que, o usuário será direcionado quando fizer o login. Essa tela contará com um dashboard centralizado no centro da página, exibindo dados de indicativos gerais sendo possível filtrar os dados por data especifica (inicio - fim), a tela deve possuir um menu de navegação e sua rota deve ser: "/home", qualquer usuário pode acessa-la e seu esquema de cores deve seguir a paleta definida. Restrições: Só poderá acessar se estiver logado. Falha: 1. Se o dashboard não possuir dados suficientes, exibir uma mensagem de dados insuficientes ao invés de exibir os dados; 2. Se o usuário tiver com a sesão expirada, no próximo evento que for acionado nesta página ele deverá ser direcionado para o Login novamente e os dados da sesão, se estiverem salvos, devem ser limpados. Conteúdo: Dashboard e Menu |
1. O usuário é direcionado para essa página assim que faz o login? 2. A rota "/home" leva para essa página? 3. O página possuí todos os componentes? 4. O dashboard consegue filtrar os dados por data? 5. O dashboard exibe a mensagem de falha no caso de falha? |
21/01/2024 | 21/01/2024 |
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:
tag_do_tipo_da_branch/descricao-id_da_task
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:
func/swagger-1
Warning
Evite caracteres especiais e acentuações nas branches.
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: Adiciona 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.
