|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência de Projeto](gp)|[Horários Disponiveis](horarios)|[Boas Práticas](Boas Praticas)|[Git](git)|
|
|
|[Home](home)|[Sprints](sprints)|[Requisitos](requisitos)|[Arquitetura](arquitetura)|[Configuração](configuracao)|[Mockups](mockups)|[Banco de Dados](banco_dados)|[Instalação](instalacao)|[Gerência de Projeto](gp)|[Horários Disponiveis](horarios)|[Boas Práticas](Boas Praticas)|[Git](git)|
|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
# Página da Arquitetura do Sistema
|
|
# Diagrama de componentes
|
|
|
|
|
|
|
|
**Atenção** -- **Atenção**
|
|
O Diagrama de componentes tem como objetivo apresentar uma ideia geral da estruturação dos componentes macro da aplicação - no caso, as telas do sistema -, mostrando como estão dispostos e com quais outros componentes interagem.
|
|
|
|
|
|
|
|
NUNCA! nunca altere as versões das dependências utilizadas :rage:.
|
|
|
|
|
A menos que seja necessário :rofl:.
|
|
|
|
|
Em alguns casos, é preferível mantê-las desatualizadas, por questões de compatibilidade.
|
|
|
|
|
Se trocar uma versão de dependência:
|
|
|
|
|
|
|
|
|
|
* Somente com aprovação de um AGES III !!!
|
|
Alguns pontos que necessitam atenção:
|
|
|
* Teste bem!
|
|
|
|
|
* e **notifique** o time para que mais testes possam ser efetuados.
|
|
|
|
|
|
|
|
|
|
## Code Review
|
|
* A comunicação com o *Firebase* deve ser feita através dos *services* **PlaceService**, **ContactsService**, **UsersService** e **AuthService**. Desta maneira, mantemos um ponto único de consumo de dados dentro da aplicação e facilitamos a manutenção no caso de erros.
|
|
|
|
|
|
|
|
Após o desenvolvimento de uma task, um *pull request* (PR) deve ser aberto com destino à branch *dev* do repositório. Todos os PRs são revisados por pelo menos dois AGES III, que se responsabilizam por garantir a qualidade do que foi desenvolvido e que os artefatos e estruturas se adequem aos padrões definidos neste documento.
|
|
* O sufixo **Model** é utilizado para denotar objetos que representam entidades no banco de dados. Estes objetos serão representados dentro do sistema por interfaces. As demais interfaces **que não representarem entidades do banco de dados** devem ser nomeadas da seguinte forma: **Nome da interface em PascalCase** + ```Interface```
|
|
|
|
|
|
|
|
Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até cinco dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).
|
|
* * Exemplo: `export interface PlaceFiltersInterface {}`
|
|
|
|
|
|
|
|
**Template** -- **Pull request**
|
|
* Componentes oferecem ou requerem alguma interface para poder se conectar com outros componentes. No exemplo da imagem abaixo, o componente **ListPlaces** espera receber um objeto, com formato definido por uma interface, do componente **FilterPlace**.
|
|
|
|
|
|
|
|
|
|
|
|
Título da User Story atrelada - Título da Issue atrelada
|
|
# Fluxogramas de uso da aplicação
|
|
|
|
|
|
|
|
Descrição do trabalho feito na tarefa e seu estado atual (tudo pronto? Algum detalhe ainda faltando?).
|
|
# Estruturação de testes |
|
|
|
|
\ No newline at end of file |
|
|
Tente explicar as coisas de forma que os AGES III entendam o que foi feito, porquê foi feito e o que eles precisam testar e validar no código desenvolvido.
|
|
|
|
|
|
|
|
|
|
**Autores:** (nome de todos que participaram da implementação)
|
|
|
|
|
|
|
|
|
|
Checklist
|
|
|
|
|
|
|
|
|
|
Deixe um dos ícones de acordo com a sua resposta para cada pergunta. (legenda abaixo)
|
|
|
|
|
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ funciona em Android
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ (opcional) funciona em iOS
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ interface funciona nos tamanhos de tela suportados
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ interface segue especificação no Figma
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ passa nos testes funcionais definidos para a tarefa/story
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ documentação atualizada
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ código dentro dos padrões
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ código sem warnings ou erros de linter (rode `npm run lint -- --fix` para ajustar e faça o commit)
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ adiciona dependências externas
|
|
|
|
|
- ✅/⚠️/❌/🤷♀️ dependências externas adicionadas foram aprovadas pelos AGES III
|
|
|
|
|
|
|
|
|
|
Legenda:
|
|
|
|
|
|
|
|
|
|
- ✅: sim (funciona/builda/documentação atualizada/...)
|
|
|
|
|
- ⚠️: parcialmente (partes não funcionam/apenas documentação pendente/...)
|
|
|
|
|
- ❌: não (não builda/não funciona/não segue padrões/sem documentação/...)
|
|
|
|
|
- 🤷♀️: não se aplica (não tenho como testar no iOS/não envolve interface/...)
|
|
|
|
|
|
|
|
|
|
Adicione um screenshot/gif da aplicação após último commit, que seja possível visualizar a alteração
|
|
|
|
|
|
|
|
|
|
Opcional, mas recomendado.
|
|
|
|
|
|
|
|
|
|
Outras informações
|
|
|
|
|
|
|
|
|
|
Comentários extras...
|
|
|
|
|
|
|
|
|
|
**Fim** -- **Template**
|
|
|
|
|
|
|
|
|
|
Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:
|
|
|
|
|
|
|
|
|
|
* Segurança
|
|
|
|
|
* Rotas de Backend (Arquitetura
|
|
|
|
|
funcional)
|
|
|
|
|
* Objects – Backend API
|
|
|
|
|
* Methods – Backend API
|
|
|
|
|
* Arquitetura Não Funcional)
|
|
|
|
|
* Diagrama de Pacotes / Componentes
|
|
|
|
|
(Arquitetura de software)
|
|
|
|
|
* Diagrama de Deploy
|
|
|
|
|
* Documentação sobre aplicação de
|
|
|
|
|
Design do Projeto
|
|
|
|
|
* Análise dos principios SOLID
|
|
|
|
|
* Code Review
|
|
|
|
|
*
|
|
|
|
|
Devem ser apresentados das seguintes formas:
|
|
|
|
|
|
|
|
|
|
* Imagens ou Gifs
|
|
|
|
|
* Diagramas ou Sistemas
|
|
|
|
|
* Descrições ou Textos explicativos |
|
|
|
\ No newline at end of file |
|
|
Guilherme De Oliveira Munaretto
