Página da Arquitetura do Sistema

Esta é a página onde irá ficar todas as informações da Arquitetura do seu projeto, Como:

• 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
• Code Review

Devem ser apresentados das seguintes formas:

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

Políticas do Git

Idealmente os commits devem ser pequenos e objetivos. O mesmo serve para Merge Requests. Commits e Merge Requests menores são mais fáceis de entender e revisar.

Branches de desenvolvimento idealmente devem existir por pouco tempo, o que reduz consideravelmente o número de conflitos e também ajuda no processo de revisão e merge.

Sobre mensagens de commit:

• Em inglês
• As mensagens devem estar no modo imperativo
• Utilizar mais ou menos 50 caracteres
• A mensagem sempre começa com letra maiúscula
• A mensagem não tem ponto final
• Sempre especificar o tipo de commit
• Usar o corpo da mensagem (quando necessário) para explicar "o que" e "por que"

Tipos de commits

• feature: Alterar comportamento, interface ou adicionar nova funcionalidade
• fix: Correção de bugs
• doc: Alteração da documentação, README, CHANGELOG, etc
• style: Formatação, ponto e vírgula faltando, mudanças de whitespace, estilo de código no geral
• refactor: Refatoração do código de produção, nenhuma ateração de funcionalidade ou comportamento
• test: Adicionar testes, refatorar testes; código de produção não é alterado
• chore: Tarefas relacionadas a infra, CI, configuração, etc

Exemplos

feature: Add search videos page
fix: Stop ignoring keywords when searching
doc: Add examples to the contributing guide
style: Remove empty line
refactor: Move related methods close together
test: Add spec for api video controller

Sobre branches:

• Master: é a base do projeto. É dela que as outras branches serão criadas. Onde ocorrerá o merge das branches de desenvolvimento. Utilizaremos Semantic Versioning para mantermos o controle de versão da nossa aplicação.
• Branches de desenvolvimento: onde novas funcionalidades são desenvolvidas e erros são corrigidos. Lembrando que elas sempre são criadas a partir da master.

Sobre Merge Requests:

• Fazer rebase com o master antes de abrir o Merge Request. Isso garante que possíveis conflitos sejam resolvidos antes do processo de revisão.

Referências:

• https://chris.beams.io/posts/git-commit/
• https://www.freecodecamp.org/news/writing-good-commit-messages-a-practical-guide/
• https://semver.org/
• https://www.conventionalcommits.org/en/v1.0.0/#summary
• https://dhwthompson.com/2019/my-favourite-git-commit

Padrões de código

Código em inglês (nomes de variáveis, funções, arquivos, etc.)

Seguiremos o guia de estilo do Dart, que é a documentação oficial para o estilo de código em Dart.

Nota: todos os guias contidos na documentação são ótimas fontes de referências e de conhecimento sobre linguagem. Recomendamos a leitura.

Referências:

• https://dart.dev/guides/language/effective-dart