|[Página Inicial](home)|
|---|

# Página da Arquitetura do Sistema

Nesta página encontra-se todas as políticas definidas pela equipe em relação ao uso do git, para tornar o desenvolvimento e uso do git mais fácil e eficiente de uma forma que todos os integrantes entendam. Também estão presentes os diagramas da aplicação, explicações sobre o Firebase e o Fluxo do funcionamento da aplicação que a equipe está desenvolvendo.

| **Conteúdo**      |
| -------------- |
| Políticas do Git |
| Padrões de Código |
| Diagrama do Fluxo de Aplicação |

## Políticas do Git

Idealmente os commits devem ser pequenos e objetivos. O mesmo serve para Merge Requests. Commits e Merge Requests menores são mais fáceis de entender e revisar.

Branches de desenvolvimento idealmente devem existir por pouco tempo, o que reduz consideravelmente o número de conflitos e também ajuda no processo de revisão e merge. 

### Sobre mensagens de commit:

- Em inglês
- As mensagens devem estar no modo imperativo
- Utilizar mais ou menos 50 caracteres
- A mensagem sempre começa com letra maiúscula
- A mensagem não tem ponto final
- Sempre especificar o tipo de commit
- Usar o corpo da mensagem (quando necessário) para explicar "o que"  e "por que"

**Tipos de commits**

- feature: Alterar comportamento, interface ou adicionar nova funcionalidade 
- fix: Correção de bugs
- doc: Alteração da documentação, README, CHANGELOG, etc
- style: Formatação, ponto e vírgula faltando, mudanças de whitespace, estilo de código no geral 
- refactor: Refatoração do código de produção, nenhuma ateração de funcionalidade ou comportamento
- test: Adicionar testes, refatorar testes; código de produção não é alterado
- chore: Tarefas relacionadas a infra, CI, configuração, etc

**Exemplos**

    feature: Add search videos page
    fix: Stop ignoring keywords when searching
    doc: Add examples to the contributing guide
    style: Remove empty line
    refactor: Move related methods close together
    test: Add spec for api video controller

### Sobre branches:

- Master: é a base do projeto. É dela que as outras branches serão criadas. Onde ocorrerá o `merge` das branches de desenvolvimento. Utilizaremos [Semantic Versioning](https://semver.org/) para mantermos o controle de versão da nossa aplicação.
- Branches de desenvolvimento: onde novas funcionalidades são desenvolvidas e erros são corrigidos. Lembrando que elas sempre são criadas a partir da `master`.
- A nomenclatura das branches de desenvolvimento seguem o template:
  `{tipo}/{id-do-card-no-trello}/{pequena-descrição}`
* As opções de tipo no nome da branch são os mesmos dos tipos de commit. 

![trello_id](uploads/98bdc7f6d9c596b3282520bed4d24d8d/trello_id.png)

### Sobre Merge Requests:

- Fazer rebase com o master antes de abrir o Merge Request. Isso garante que possíveis conflitos sejam resolvidos antes do processo de revisão.

- Sempre marque para remover a branch depois do merge.

![delete_source_branch](uploads/fb734476afb6ff12d8aca29b6bdf9c87/delete_source_branch.png)

### Sobre Issues

Ao decorrer do projeto, além do desenvolvimento de novas features, é necessário corrigir bugs e outros erros que decorrem do desenvolvimento. Nem sempre nós temos tempo para corrigi-los, as vezes queremos opiniões de outros desenvolvedores em como resolver um problema, ou apenas queremos discutir o desenvolvimento de alguma funcionalidade. Para isso, existem as `Issues`.

Quando criar uma Issue, tente escrever um título curto, mas que expresse qual o problema. Na descrição, fale mais sobre o problema, como reproduzi-lo (caso seja algo muito específico), como pensa em resolve-lo (se não souber como, não tem problema) e qualquer outra coisa que julgue ser necessário.

Quando tiver corrigido um problema, na mensagem do commit que resolve aquele problema, coloque:
```   
Closes #<numero_da_issue>
```

Isso permite que a Issue seja fechada automaticamente pelo GitLab. Além disso, na Issue, fica a hash do commit que fechou ela, então fica documentado para qualquer necessidade de referência futura.


Para mais informações sobre Issues acesse a [documentação oficial do GitLab sobre essa feature](https://docs.gitlab.com/ee/user/project/issues/).

### Referências:

- https://chris.beams.io/posts/git-commit/
- https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/
- https://semver.org/
- https://www.conventionalcommits.org/en/v1.0.0/#summary
- https://dhwthompson.com/2019/my-favourite-git-commit
- https://docs.gitlab.com/ee/user/project/issues/

## Padrões de código

Código em inglês (nomes de variáveis, funções, arquivos, etc.)

Seguiremos o [guia de estilo do Dart](https://dart.dev/guides/language/effective-dart), que é a documentação oficial para o estilo de código em Dart.

> Nota: todos os guias contidos na documentação são ótimas fontes de referências e de conhecimento sobre linguagem. Recomendamos a leitura.

### Referências:

- https://dart.dev/guides/language/effective-dart

## Diagrama do Fluxo da Aplicação

![fluxoDeAtividades__3_](uploads/73191d13c66038a61e9ad78713525642/fluxoDeAtividades__3_.png)