Arquitetura do Sistema

• Fluxograma de funcionamento do aplicativo
• Git Branching Model
• Code Review
• Guia de desenvolvimento
• Próximos artefatos

Fluxograma de funcionamento do aplicativo

Este fluxograma é referente à aplicação mobile que tem como principal função a coleta do tempo das atividades.

Perceba que num primeiro momento estamos abstraindo o fluxo de inserção de dados, considere que estes já estarão disponíveis na API. Nossa prioridade é o desenvolvimento do App (Android e IOS) para coleta de tempos, para que posteriormente possamos dedicar tempo para as tarefas administrativas (Cadastrar Hospitais, Cadastrar Processos - que contém atividades -).

É possível notar que não é necessário login para o uso de funcionários e bolsistas, estes só precisam identificar o respectivo hospital, para que sejam vinculados os processos e atividades referentes à sua função. A identificação do paciente é apenas para identificar e diferenciar possíveis processos parecidos sendo realizados ao mesmo tempo. Esta identificação deve ser feita de forma que facilite o máximo possível o atendimento. Possíveis identificações: Iniciais do paciente, Código do atendimento do paciente no hospital ou outro. (Esta identificação deve ser informada no momento no fluxo apresentado).

Git Branching Model

O modelo de gestão das branches do Git é baseado no Git Flow "trandicional" com adaptações. Não é previsto o uso de branches hotfix/*, uma vez que na AGES não há situações onde um ajuste do produto entregue será integrado antes do final da sprint corrente.

O desenvolvimento nos repositórios app e api deve seguir o fluxo de Git aqui definido:

• uma branch master com o código atualmente em produção;
• uma branch develop com o código em desenvolvimento, com funcionalidades finalizadas mas ainda em fase de testes para validação;
• feature branches para tasks relacionadas às user stories a serem desenvolvidas. Uma branch de task deve ser nomeada com o número único da task, seguida da breve descrição da task (por exemplo, feature/t06-login ou feature/t24-reports-ui);
• quando uma feature é finalizada, um PR da branch feature/ relacionada é aberto com destino à branch develop.

O código da develop é integrado com a master ao final da sprint, após validação dos stakeholders do que foi desenvolvido.

Dessa forma, o fluxo usual de trabalho é o seguinte:

1. antes de iniciar o desenvolvimento de uma task, fazer checkout para a branch develop e pegar as últimas atualizações (pull);
2. criar uma branch para a task com o ID da task (feature/tXX-YYYYY);
3. "enviar" a branch para o remoto (git push -u origin feature/tXX-YYYYY);
4. desenvolver, commitar mudanças e atualizar o remoto (push);
5. voltar para o item 4 até finalizar a task;
6. abrir um PR com destino à branch develop;
7. mover o card da task no Trello para a lista Code Review e avisar no Slack (canal #code-review) que a task está pronta para review;
8. fim! 😃

Padrões de commit

Quando realizar um commit, tente manter o seguinte padrão nas mensagens:

• título: número da task e breve descrição da mudança;
• se preciso, adicione um descrição mais longa da mudança, do porquê ela se faz necessária ou do porquê foi feito dessa forma; essa descrição longa deve estar separada do título por uma linha em branco;
• se mais de uma pessoa participou das mudanças do commit: indique a co-autoria conforme exemplo abaixo, também separada por uma linha em branco da descrição longa (o Git precisa de um formato bem específico nessa parte, com uma pessoa por linha; não é preciso adicionar uma linha para a pessoa que está fazendo o commit, porque o Git já pega isso automaticamente).

Exemplo:

#48: Fix patient name field placeholder

The placeholder was clipped smartphones with small screens; reduced placeholder
length for better UX on those devices.

Co-authored-by: Marcos Silva <[email protected]>

Code Review

Após o desenvolvimento de uma task, um pull/merge request (PR) deve ser aberto com destino à branch develop do repositório relativo à task: app ou api. 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.

Os AGES III se comprometem a revisar os PRs o mais rápido possível, garantindo que PRs abertos até dois dias antes de uma entrega serão integrados (se cumprirem todas as regras do code review).

Foram definidas algumas regras usadas durante o processo de code review dos PRs abertos nos repositórios:

• app:

  • funciona obrigatoriamente em Android, preferencialmente em iOS;
  • interface funciona nos tamanhos de tela suportados;
  • interface segue especificação no Figma;
  • conforme critérios de aceitação para a tarefa;
  • 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.

• api:

  • funciona conforme especificação no Postman;
  • possui testes de unidade associados;
  • mantém cobertura de pelo menos 50%;
  • dependências externas adicionadas aprovadas pelos AGES III;
  • documentação atualizada;
  • código dentro dos padrões;
  • código sem warnings ou erros de linter.

Essas regras foram adicionadas como template de PR em cada projeto.

Guia de desenvolvimento

Foi criado um guia de desenvolvimento para o backend, com o intuito de auxiliar no processo de entendimento da arquitetura de camadas usada no backend, organização física do repositório e acesso à documentação das rotas.

🔗 Acesse o guia de desenvolvimento.

Próximos possíveis artefatos:

• 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

Devem ser apresentados das seguintes formas:

• Imagens ou Gifs
• Diagramas ou Sistemas
• Descrições ou textos explicativos