#Descrição do teste
Eu Jorge procuro uma solução de agenda de reuniões para satisfazer as minhas necessidades e a da minha sócia Clara e dos meus colaboradores:
- Eu como usuário quero dizer se o agendamento realizado foi aceito ou não.
- Eu como usuário não quero ter múltiplos agendamentos no mesmo horário.
- Eu como usuário quero filtrar as atividades por range de data, ex.: do dia 21/12/2010 até 10/01/2029.
- Eu como usuario trabalho somente em horário comercial, não trabalho aos finais de semana e feriados oficiais do Brasil(feriados municipais e estaduais não contam).
- Eu como usuário quero poder criar e listar os agendamentos(Somente a Clara pode editar e excluir).
- Eu Jorge quero ser notificado por e-mail toda vez que um agendamento de reunizo for solicitado.
- Os clientes deve informar o e-mail, nome, data, horário e a pauta da reunião;
- Meus clientes podem visualizar os horários já preenchidos, mas não pode ver as informações sensíveis.
- A minha agenda deve conter, data de início, data de conclusão, tempo de duração da reunião, quem solicitou(pode ter solicitações internas de outro sócio), com quem foi agendada e se foi aceita.
#Requisitos:
- Neste teste deverá ser utilizado o framework LARAVEL como base de desenvolvimento.
- A aplicação de backend deverá ser uma API Restful;
- A aplicação de frontend deverá ser utilizando Vue.Js e consumir a API Restful;
- A aplicação deverá ser entregue através de um link no github.
- No readme deve conter a descrição da abordagem utilizada para solucionar o problema em cada um dos projetos.
- Requisitos técnicos que deverá ser levado em consideração durante a elaboração da solução.
#Backend:
- Utilizar Repository Pattern.
- Utilização dos conceitos de SOLID e Clean Architecture.
- Services.
- Testes Unitários.
- Seeders.
- PSR.
- Fractal ou ApiResources.
- Padrão da url.
- Interfaces.
- Migrations.
- Todas as variáveis de configurações de acessos a banco de dados e demais integrações devem estar no .ENV do projeto.
#Frontend:
- Lint.
- Utilização dos conceitos de SOLID e Clean Architecture.
- Testes unitários com Jest.
- Utilização dos componentes.
- Tolerância a falhas caso a API esteja Offline.
- Todas as variáveis de configurações de acessos a API e demais integrações devem estar no .ENV do projeto.
#Critérios de Avaliação
- Entrega
- O projeto está completo para ser executado?
- O projeto atende ao que se propõe fazer?
- Todos requisitos foram atendidos?
- Boas Práticas
- O código está de acordo com o guia de estilo do PHP/Vue?
- O código está bem estruturado, seguindo os princípios SOLID, PSR e Lint?
- O código está fluente na linguagem?
- O código faz o uso correto de Design Patterns?
- Os commits são pequenos e consistentes?
- As mensagens de commit são claras?
- Documentação (README)
- O código foi entregue com um arquivo de README claro de como se guiar?
- A documentação foi suficiente para executar o projeto?
- Código Limpo
- O código possibilita expansão para novas funcionalidades?
- O código é Don't Repeat Yourself?
- O código é fácil de compreender?
- Controle de Qualidade
- O código possui configuração de PSR e Lint?
- O código possui testes unitários?