Grupo: Bruno Henrique, Cauã Marcos e Gabriel Furtado. Turma 10A
Consiste em um sistema web que permite a realização de pedidos de um determinado restaurante mexicano online.
As principais funcionalidades na visão do cliente são: visualizar o cardápio, realizar o pedido e efetuar o pagamento. Já na visão do gerente/funcionario, as principais funcionalidades são: adicionar, alterar e excluir produtos, como também visualizar pedidos.
Os tipos de usuários previstos são os clientes desse respectivo restaurante, e também quem gerencia e trabalha com o sistema.
Deve-se estruturar a mensagem do commit da seguinte forma:
<tipo>[escopo opcional]: <descrição>
[corpo opcional]
[rodapé(s) opcional(is)]O tipo deve ser algum dos seguintes:
O escopo deve ser o nome do pacote npm afetado. A seguir está a lista de escopos suportados:
O corpo deve incluir a motivação para a mudança e compará-la com o comportamento anterior.
O rodapé deve conter qualquer informação sobre BREAKING CHANGES e também é o local para referenciar as issues do GitHub que este commit Close.
BREAKING CHANGES contém no rodapé opcional o texto BREAKING CHANGE: ou contém o símbolo ! depois do tipo/escopo, introduz uma modificação que quebra a compatibilidade da API. Uma BREAKING CHANGE pode fazer parte de commits de qualquer tipo.
O modelo será composto por dois branches, o principal e o de features:
Regra: Adotar e manter um padrão consistente de notação de código em todo o projeto. Utilizar camelCase para variáveis, PascalCase para nomes de classes, e seguir outras convenções de nomenclatura para garantir consistência e clareza no código.
Regra: Incluir comentários relevantes quando necessário para explicar trechos complexos ou algoritmos. Evitar comentários redundantes e priorizar um código autoexplicativo.
Regra: Aplicar os princípios SOLID no design de código para promover a coesão e a flexibilidade, principalmente com relação ao princípio da responsabilidade única.
Regra: Seguir as diretrizes do CLEAN CODE, mantendo funções curtas e focadas, evitando duplicação de código, escolhendo nomes descritivos e adotando outras práticas que contribuem para um código claro, legível e de fácil manutenção.
Regra: Escrever testes unitários para validar a funcionalidade correta do código. Adotar práticas de Desenvolvimento Orientado a Testes (TDD) quando possível para garantir que o código seja testado desde o início do desenvolvimento.
Regra: Utilizar um sistema de controle de versão, como Git, para rastrear mudanças no código. Realizar commits frequentes e significativos, proporcionando um histórico claro e reversível das alterações. Integrar a colaboração e facilitar a gestão do desenvolvimento em equipe.