Arquitetura do Sistema

• Fluxograma de funcionamento do aplicativo
• Git Branching Model
• Code Review
• 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! 😃

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:

  • a funcionalidade desenvolvida deve funcionar conforme os critérios de aceitação definidos na especificação da user story relacionada, obrigatoriamente em Android e preferencialmente em iOS;
  • a interface desenvolvida está em conformidade com as telas desenvolvidas no Figma (quando a task é relacionada a interface);
  • a interface desenvolvida deve funcionar corretamente nos tamanhos de tela suportados pela aplicação (quando a task é relacionada a interface);
  • o PR deve implementar preferencialmente apenas uma task, e obrigatoriamente apenas tasks da mesma user story;
  • a adição de novas dependências deve ser previamente validada pelos AGES III;
  • o código desenvolvido deve conformar com as regras de linter estabelecidas (presentes no repositório app);
  • o código desenvolvido deve possuir documentação apropriada.

• api:

  • a funcionalidade (rota) desenvolvida deve funcionar conforme contrato APP-API definido (formato dos requests e responses, pré- e pós-condições); se o contrato APP-API for modificado, a documentação no Postman deve estar atualizada;
  • a funcionalidade deve estar coberta por testes de unidade e integração, com pelo menos 50% de cobertura;
  • a funcionalidade deve seguir a arquitetura e projeto documentados;
  • o PR deve implementar preferencialmente apenas uma task, e obrigatoriamente apenas tasks da mesma user story;
  • a adição de novas dependências deve ser previamente validada pelos AGES III;
  • o código desenvolvido deve conformar com as regras de linter estabelecidas (presentes no repositório app);
  • o código desenvolvido deve possuir documentação apropriada.

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

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
• Plano de code review

Devem ser apresentados das seguintes formas:

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