Padrão de Projetos - Parte II

Na primeira parte eu falei de um script que ajuda no versionamento semântico com commits convencionais e changelog. Veja a primeira parte se você não leu aqui.

Nesta parte vamos preparar o projeto para economizar tempo. Padrão significa economia de tempo, energia mental e busca de tecnologia.

O ambiente de programação

A maioria dos projetos que fazemos estão em tecnologias opensource. Isso é: typescript (eu aboli JS), PHP, Go e Rust. Scripts em python e bash. Existe um pouco de C e C++, mas é mínimo e bem básico. Para isso eu uso o VSCODE.

Dentro de cada projeto existe um diretório chamado .vscode. Ele serve para colocarmos arquivos que dirá ao vscode o que fazer. Basicamente colocamos dois arquivos dentro desta pasta: um para extensões e outro para configurações.

Arquivos

settings.json

settings.json

{
    "cSpell.language": "en,pt,pt-BR",
    "cSpell.enabledFileTypes": {
       "markdown": true
    },
    "cSpell.ignorePaths": [
       "package-lock.json",
       "node_modules",
       "vscode-extension",
       ".git/{info,lfs,logs,refs,objects}/**",
       ".git/{index,*refs,*HEAD}",
       ".vscode",
       ".vscode-insiders",
       "**/**.sh",
       "**/**.env",
       "src/**",
       "dist/**",
       "scripts/**"
    ],
    "workbench.colorCustomizations": {
	    "editorInfo.foreground": "#ff0000"
    },
    "insertDateString.formatDate": "DD-MM-YYYY",
    "markdown-preview-enhanced.plantumlServer": "https://kroki.io/plantuml/svg/"
}

O arquivo settings diz respeito a configuração do VSCODE. O arquivo acima está apresentando algumas linhas de configuração de extensões. Dentro do repositório padrão teremos alguns tipos de configuração para que não existam problemas. É... dependendo do que você irá fazer, existe um setup adequado.

Alguns padrões iniciais

Em virtude de problemas que possam acontecer, decidi padronizar alguns padrões para melhorar a comunicação:

1. Diagramas UML apenas no kroki

   1. Integra o plantuml
   2. Integra o mermaid
   3. Integra inúmeros outros diagramas que você consegue ver no kroki.

2. Cspell como dicionário. É necessário instalar o Cspell e o pacote pt-br. As linhas acima de ignorepaths são os arquivos que ele não corrige como parte do processo.

3. Dentro do meu editor eu prefiro que as correções estejam grifadas em vermelho. Isso porque é muito mais fácil de encontrar e analisar.

4. Eu utilizo um padrão para formatar data e hora por conta de procedimentos.

5. Apenas markdown em documentação.

Algumas extensões recomendadas

1. emojisense
   1. Emoji é uma forma de comunicação eficiente
2. gitignore
   1. Adiciona arquivos ao .gitignore apenas com um clique do botão direito
3. insertdatestring
   1. Essa extensão permite que você formate o atalho para inserir data e hora. É muito útil em documentação
4. markdown all in one
   1. A melhor extensão de markdown que existe.
5. markdown kroki
   1. Suporte a diagramas suportados pelo kroki em markdown
6. TODO plus
   1. Depois vou falar desta extensão. Mas para anotações dentro do código ela é o que existe de mais interessante.

Estrutura de diretório

A estrutura de diretório pode seguir o modelo abaixo:

• Raiz do projeto
  • .github (para projetos que utilizem customização do github)
  • .vscode (explicação acima)
  • .husky (Husky NPM - ver primeiro artigo)
  • docker(configurações do docker)
  • docker-compose.yml
  • package.json
  • scripts (scripts de instalação)
  • .versionrc (standard version - o que sai no changelog)
  • README.md
  • CHANGELOG.md (gerado por comando e não criado)
  • commitlint.config.js

Essa é uma estrutura de diretórios em início de projeto.

O que pode conter o inicio de um projeto?

Basicamente as seguintes premissas:

1. Commits Convencionais
2. Versionamento Semântico
3. Changelog Automático

Esse é o básico. Depois os opcionais:

1. Docker
   1. Isso auxilia a padronizar a execução. Geralmente um yaml para o compose e um diretório contendo as configurações de alguns aplicativos.
2. Scripts
   1. Eu deixo scripts, principalmente os que auxiliam em actions (devops) em um local separado.
3. DevOps
   1. Caso seja github um padrão do github/workflows. No gitlab é .gitlab-ci.yml

---

Isso é a segunda parte do padrão.

até a próxima.