Hoje vamos abordar alguns temas ainda conceituais, porém que são de extrema importancia para qualquer projeto de software, pois ajuda na organização e padronização do código que vai ser desenvolvido.
Os temas de hoje são versionamento semântico e convenção de nomes. Estes dois temas são muito comuns para desenvolvedores que já possuem experiencia com linguagens de programação como JAVA, PHP, Python, etc, porém percebi que não é um tema muito comum para quem vem de outras áreas de TI ou mesmo para quem vem de outras plataformas low-code / no-code.
Então para alinharmos o conhecimento e começarmos a escrever códigos melhores, vamos na aula de hoje abordar os temas versionamento semântico e convenção de nomes.
O primeiro tema que vamos abordar é versionamento semântico.
Versionamento Semântico (Semantic Versioning)
Controle de Versão de um software é o gerenciamento das mudanças do código fonte do mesmo. Para desenvolvedores, é crítico ter um sistema de controle de versão, para que seja possível que múltiplos desenvolvedores possam contribuir com o código sem um interferir no outro.
O versionamento semântico é um padrão simples de ser entendido, mas de extrema importancia. Ele consiste em uma forma padronizada de versionar qualquer produto que possa ter como característica: quebra de compatibilidade (breaking changes), novas funcionalidaces (new functionalities) e correção de erros (bugfix).
O mais simples é iniciar o desenvolvimento de uma nova aplicação/produto/API com a versão 0.1.0, e então ir incrementando a versão Minor para cada release seguinte.
Quando o software começar a ser utilizado em produção ou você tiver um produto estável, você deverá alterar a versão para 1.0.0.
A imagem apresenta exatamente a estrutura basica adotada pelo versionamento semântico. Neste caso temos a versão 4.7.6
O 4 representa a major version o que significa por exemplo que esta versão 4.X.X possui quebra de compatibilidade com as versões anteriores (major versions), por exemplo, 3.X.X, 2.X.X e 1.X.X
O segundo número, neste caso o 7, representa uma minor version. Neste caso podemos exemplificar uma minor version como uma funcionalidade que foi adicionada mas que não gera nenhuma quebra de compatibilidade.
Já o 6 representa uma correção de erro. Ou seja, a minor version 7 da major version 4, já teve 6 correções de bugs/falhas.
O diagrama a seguir apresenta exatamente um exemplo de versionamento considerando as características mencionadas anteriormente (nova funcionamlidade, correção de erro).
Neste caso temos um produto já estável, onde foi atribuido a versão 1.0.0.
Após o desenvolvimento de uma nova funcionalidade, foi atribuido a versão 1.1.0
Foi identificado que a versão 1.1.0 possuia um erro (bug) que após sua correção levou a ser atribuido a versão 1.1.1
Em cima da versão 1.1.1 foi desenvolvida uma nova funcionalidade o que levou a ser atribuido a versão 1.2.0
Foi identificado o mesmo erro (bug) tanto na versão 1.1.0 quanto na versão 1.2.0, o que após sua correção, levou a versão 1.1.1 a 1.1.2 e a versão 1.2.0 a 1.2.1.
Ao final, foi gerado uma nova funcionalidade sobre a versão 1.2.1 e com isso foi atribuido a versão 1.3.0
E assim sucessivamente.
Vale lembrar que, no momento que algo for desenvolvido ou corrigido e fizer com que se quebre a compatibilidade, neste momento será gerado a versão 2.0.0 e todo o ciclo de atribuição de versão reinicia, de forma muito semelhante ao exemplo apresentado.
Vamos ver alguns exemplos no Exchange e no Anypoint Studio.
Convenção de Nomes (Naming Conventions)
Outro tema importante de abordarmos é a convenção de nomes. Este assunto é muito importante pois assim padronizamos a forma que escrevemos software, ou seja, todos os desenvolvedores fazem uso do padrão adotado e este padrão é utilizado de forma consistente por todo o projeto.
Existem 4 tipos mais utilizados de convenção de nomes (naming conventions). Vamos ver cada um deles e onde se aplicam.
Camel Case (camelCase)
Camel Case combina palavras capitalizando todas as palavras após a primeira palavra e removendo o espaço, da seguinte forma:
- Original: user login count
- Camel Case: userLoginCount
Esta é uma maneira muito popular de combinar palavras para formar um único conceito. É frequentemente usado na declaração de variáveis em muitas linguagens.
Pascal Case (PascalCase)
O Pascal Case combina palavras colocando todas as palavras em maiúsculas (a primeira palavra) e removendo o espaço, como segue:
- Original: user login count
- Pascal Case: UserLoginCount
Essa também é uma maneira muito popular de combinar palavras para formar um único conceito. É frequentemente usado na declaração de classes em muitas linguagens.
Snake Case (snake_case)
Snake Case combina palavras substituindo cada espaço por um sublinhado (_) e, na versão em maiúsculas, todas as letras são maiúsculas, como segue:
- Original: user login count
- Snake Case: user_login_count
- Snake Case (todas em maiúsculas): USER_LOGIN_COUNT
Esse estilo, quando em maiúsculas, é frequentemente usado como convenção na declaração de constantes. Quando em letras minúsculas, é usado convencionalmente na declaração de nomes de campos do banco de dados.
Kebab Case (kebab-case)
Kebab Case combina palavras substituindo cada espaço por um traço (-), como segue:
- Original: user login count
- Kebab Case: user-login-count
Esse estilo é frequentemente usado em URLs (url amigável).
Por exemplo, www.blog.com/meu-artigo-1.
public class PascalCase {
String camelCase = "minha variável do tipo String";
final int ANO_ATUAL = 2022;
public String camelCase() {
return "https://www.mulesoft.com/platform/cloud-connectors";
}
}
Assim encerramos os dois assunto da aula de hoje. Eu te vejo na próxima aula.