Skip to content

Latest commit

 

History

History
475 lines (315 loc) · 17.2 KB

README.old.md

File metadata and controls

475 lines (315 loc) · 17.2 KB
Raw

Burger Queen (API Client)

Índice

1. Prefácio

Um pequeno restaurante de hambúrgueres, que está crescendo, necessita uma interface em que se possa realizar pedidos utilizando um tablet, e enviá-los para a cozinha para que sejam preparados de forma ordenada e eficiente.

Este projeto tem duas áreas: interface (cliente) e API (servidor). Nosso cliente nos pediu para desenvolver uma interface que se integre com a API que outra equipe de desenvolvedoras está trabalhando simultaneamente.

React é um dos frameworks e bibliotecas de JavaScript mais usados na área de desenvolvimento ao redor do mundo e existe uma razão para isso. No contexto do navegador, manter a interface sincronizada com o estado é difícil. Ao eleger um framework ou biblioteca para nossa interface, nos apoiamos em uma série de convenções e implementações testadas e documentadas para resolver um problema comum a toda interface web. Isto nos permite concentrar melhor (dedicar mais tempo) nas características específicas de nossa aplicação.

Quando escolhemos uma destas tecnologias não só importamos um pedaço de código para reusar (o qual já é um grande valor por si só), mas também adotamos uma arquitetura, uma série de princípios de design, um paradigma, algumas abstrações, um vocabulário, uma comunidade, etc...

Como desenvolvedora Front-End, estes kits de desenvolvimento podem resultar em uma grande ajuda para implementar rapidamente características dos projetos em que você for trabalhar.

2. Resumo do projeto

Desta vez temos um projeto 100% por demanda. Você sempre pode (e deve) fazer sugestões de melhora e mudança, mas muitas vezes trabalhará em um projeto em que primeiro deve se assegurar de cumprir os requisitos.

burger-queen

Estas são as informações que temos do cliente:

Somos Burger Queen, um fast food 24hrs.

A nossa proposta de serviço 24 horas foi muito bem recebida e, para continuar a crescer, precisamos de um sistema que nos ajude a receber pedidos de nossos clientes.

Nós temos 2 menus. Um muito simples para o café da manhã:

Ítem Preço R$
Café americano 5
Café com leite 7
Sanduíche de presunto e queijo 10
Suco de fruta natural 7

E outro menu para o resto do dia:

Ítem Preço
Hambúrgueres R$
Hambúrguer simples 10
Hambúrguer duplo 15
Acompanhamentos R$
Batata frita 5
Anéis de cebola 5
Bebidas R$
Água 500ml 5
Água 750ml 7
Bebida gaseificada 500ml 7
Bebida gaseificada 750ml 10

Importante: Os clientes podem escolher entre hambúrgueres de carne bovina, frango ou vegetariano. Além disso, por um adicional de R$ 1,00 , eles podem adicionar queijo ou ovo.

Nossos clientes são bastante indecisos, por isso é muito comum que eles mudem o seu pedido várias vezes antes de finalizar.

A interface deve mostrar os dois menus (café da manhã e restante do dia), cada um com todos os seus produtos. O usuário deve poder escolher que produtos adicionar e a interface deve mostrar o resumo do pedido com o custo total.

out

Além disso a cliente nos deu um link da documentação que especifica o comportamento esperado da API que iremos expor por HTTP. Lá podemos encontrar todos os detalhes dos endpoints, como por exemplo que parâmetros esperam, o que devem responder, etc.

O objetivo principal é aprender a construir uma interface web usando o framework escolhido (React). Esse framework front-end ataca o seguinte problema: como manter a interface e estado sincronizados. Portanto, esta experiência espera familiarizá-la com o conceito de estado da tela, e como cada mudança no estado vai refletir na interface (por exemplo, toda vez que adicionamos um produto para um pedido, a interface deve atualizar a lista de pedidos e o total).

3. Objetivos de aprendizagem

Reflita e depois enumere os objetivos que quer alcançar e aplique no seu projeto. Pense nisso para decidir sua estratégia de trabalho.

HTML

CSS

JavaScript

Git e GitHub

  • Git: Instalação e configuração

  • Git: Controle de versão com git (init, clone, add, commit, status, push, pull, remote)

  • Git: Integração de mudanças entre ramos (branch, checkout, fetch, merge, reset, rebase, tag)

  • GitHub: Criação de contas e repositórios, configuração de chave SSH

  • GitHub: Implantação com GitHub Pages

    Links

  • GitHub: Colaboração pelo Github (branches | forks | pull requests | code review | tags)

  • GitHub: Organização pelo Github (projects | issues | labels | milestones | releases)

HTTP

react

  • jsx

  • components

  • events

  • lists-and-keys

  • conditional-rendering

  • lifting-up-state

  • hooks

  • css-modules

  • routing

UX (User eXperience)

  • Desenhar a aplicação pensando e entendendo o usuário

  • Criar protótipos para obter feedback e iterar

  • Aplicar os princípios de desenho visual (contraste, alinhamento, hierarquia)

  • Planejar e executar testes de usabilidade

4. Considerações gerais

Este projeto deve ser feito em pares. Lembre-se que deverá consumir a API Burger Queen API.

Trabalhe integralmente uma história de usuário antes de passar para a próxima. Cumpra todas as histórias possíveis dentro do tempo especificado.

A lógica do projeto deve ser totalmente implementada em JavaScript (ES6 +), HTML e CSS e empacotada de forma automatizada.

Neste projeto você deve usar React.

O aplicativo deve ser um Single Page App. Os pedidos serão enviados por meio de um tablet, mas não queremos um aplicativo nativo, mas sim um aplicativo Web que seja mobile-first.

Precisamos pensar bem sobre o UX para aqueles que vão receber os pedidos, o tamanho e a aparência dos botões, a visibilidade do estado atual do pedido, etc.

A aplicação deve seguir 80% ou mais das pontuações de Performance, Progressive Web App, Accessibility e Best Practices do Lighthouse.

O aplicativo deve fazer uso de npm-scripts e ter scripts start, test, build e deploy, que são responsáveis por inicializar, rodar os testes, empacotar e fazer deploy do aplicativo, respectivamente.

Os testes unitários devem cobrir um mínimo de 90% de statements, functions, lines e branches.

Por outro lado, vocês devem definir a estrutura das pastas e arquivos que considerem necessários. Você pode estruturá-los de acordo com as convenções do framework escolhido. Portanto, os testes e os setups necessários para executá-los serão feitos por você.

5. Critérios de aceitação mínimos do projeto

Definição do produto

O Product Owner nos apresentou este backlog que é o resultado do seu trabalho com o cliente até hoje.

[Historia de usuario 1] Garçom/Garçonete deve poder entrar no sistema, caso o admin já lhe tenha dado as credenciais

Eu, como garçom/garçonete quero entrar no sistema de pedidos.

Critérios de aceitação

O que deve acontecer para satisfazer as necessidades do usuário?

  • Acessar uma tela de login.
  • Inserir email e senha.
  • Receber mensagens de erros compreensíveis, conforme o erro e as informações inseridas.
  • Entrar no sistema de pedidos caso as credenciais forem corretas.
Definição de pronto

O acordado abaixo deve acontecer para dizer que a história está terminada:

  • Você deve ter recebido code review de pelo menos uma parceira.
  • Fez testes unitários e, além disso, testou seu produto manualmente.
  • Você fez testes de usabilidade e incorporou o feedback do usuário.
  • Você deu deploy de seu aplicativo e marcou sua versão (tag git).

[História de usuário 2] Garçom/Garçonete deve ser capaz de anotar o pedido do cliente

Eu como garçom/garçonete quero poder anotar o pedido de um cliente para não depender da minha memória, saber quanto cobrar e poder enviar os pedidos para a cozinha para serem preparados em ordem.

Critérios de aceitação

O que deve acontecer para satisfazer as necessidades do usuário?

  • Anotar o nome do cliente.
  • Adicionar produtos aos pedidos.
  • Excluir produtos.
  • Ver resumo e o total da compra.
  • Enviar o pedido para a cozinha (guardar em algum banco de dados).
  • Funcionar bem em um tablet.
Definição de pronto

O acordado abaixo deve acontecer para dizer que a história está terminada:

  • Você deve ter recebido code review de pelo menos uma parceira.
  • Fez testes unitários e, além disso, testou seu produto manualmente.
  • Você fez testes de usabilidade e incorporou o feedback do usuário.
  • Você deu deploy de seu aplicativo e marcou sua versão (tag git).

[História de usuário 3] Chefe de cozinha deve ver os pedidos

Eu como chefe de cozinha quero ver os pedidos dos clientes em ordem, poder marcar que estão prontos e poder notificar os garçons/garçonetes que o pedido está pronto para ser entregue ao cliente.

Critérios de aceitação
  • Ver os pedidos ordenados à medida em que são feitos.
  • Marcar os pedidos que foram preparados e estão prontos para serem servidos.
  • Ver o tempo que levou para preparar o pedido desde que chegou, até ser marcado como concluído.
Definição de pronto
  • Você deve ter recebido code review de pelo menos uma parceira.
  • Fez testes unitários e, além disso, testou seu produto manualmente.
  • Você fez testes de usabilidade e incorporou o feedback do usuário.
  • Você deu deploy de seu aplicativo e marcou sua versão (tag git).

[Historia de usuário 4] Garçom/Garçonete deve ver os pedidos prontos para servir

Eu como garçom/garçonete quero ver os pedidos que estão prontos para entregá-los rapidamente aos clientes.

Critérios de aceitação
  • Ver a lista de pedidos prontos para servir.
  • Marcar os pedidos que foram entregues.
Definição de pronto
  • Você deve ter recebido code review de pelo menos uma parceira.
  • Fez testes unitários e, além disso, testou seu produto manualmente.
  • Você fez testes de usabilidade e incorporou o feedback do usuário.
  • Você deu deploy de seu aplicativo e marcou sua versão (tag git).
  • Os dados devem ser mantidos intactos, mesmo depois que um pedido for finalizado. Tudo isso para poder ter estatísticas no futuro.

6. Pistas, tips e leituras complementares

Frameworks / bibliotecas

Ferramentas

Rotas

PWA

Deploy