DEV Community: Rogério dos Santos Fernandes

Git - Dicas rápidas pra uma boa gestão do seu código

Rogério dos Santos Fernandes — Mon, 10 Aug 2020 21:41:00 +0000

Nada como saber usar bem as ferramentas que você tem à sua mão, não é mesmo?

Como disse Kent Becks:

não precisamos ser programadores excepcionais, mas bons programadores com excelentes hábitos.

Tá, não deve ter sido exatamente isso que ele disse, mas você entendeu.

escolha um padrão que você e seu time sigam. Pelo menos inicie de um e adapte de acordo com seu time e projeto. Dois bem conhecidos são o Git Flow e o Trunk Based Development. O primeiro é mais simples mas tem problemas ao escalar (filas de PRs). O segundo exige maturidade técnica e de qualidade, pois os commits são na master.
A partir de um padrão, recomendo colocar um sistema para rodar validações a cada commit ou push. Existe o husky para projetos baseados em NodeJS. Isso pois por mais que tenha carinho e atenção, a maior segurança vem dessas validações.
Outra coisa é: Leia o terminal! Olha o que a ferramenta ta te dizendo sobre como está seu repositório...ela vai te dar dicas valiosas. Vai te indicar a usar um comando ou outro dependendo do cenário. Leia o terminal!

Abaixo os comandos que mais uso no meu dia a dia:

git status -> pra ver o estado do seu repo local em comparação com o remoto (esse vcs já devem usar diariamente)
git add -p -> pra ir vendo em pequenos pedaços (chunks) de código o diff do que foi mexido, e ir incluindo ou não. É uma forma interativa de criar o package do commit
git commit -m "mensagem padronizada" -> cria o pacote a ser enviado ao repo remoto, recomendo padrão commit lint, é possível utilizar ferramentas pra analisar os commits
git stash/git stash pop -> esse comando armazena as suas alterações em uma fila, e restaura o estado que estava na sua branch. Uso quando quero guardar o que estava fazendo rapidamente e ir pra outra branch, por exemplo. Mas também é viável e até mais recomendável commitar e depois usar ammend pra rescrever o commit WIP (Work in progress).
git commit --amend --no-edit -> uso quando quero adicionar algo ao commit anterior sem editar a mensagem. Use com cuidado, exige um git push -f após
git rebase <BRANCH_NAME> -> atualiza sua branch com outra, mas diferente do merge, pull ou fetch, que trazem as alterações acima da sua, o rebase reescreve a história da sua branch, removendo sua alteração, colocando a história da branch indicada no comando, e aí sim colocando seus commits novamente. Por isso quando você for resolver conflitos após este método você verá suas alterações como novas, e o código "antigo" na verdade já terá atualização do rebase. Também obriga o uso de git push -f após seu uso! Use com carinho.
git push -> envia todas suas alterações para o repo remoto.
git revert -> esse comando remove certo commit do histórico. Muito útil quando um commit acabou quebrando algo, gerando um comportamento inexperado que os testes não pegaram, e você quer remover pra depois voltar corrigido.

Para resolver conflitos de Merge, recomendo uma interface como o VS Code. Facilita muito a vida!

Algumas dicas gerais seriam: Commits pequenos e constantes. Rebases constantes. Comunicação constante entre o time. O versionamento vai refletir o entrosamento (ou falta de) do time, assim como a organização das tarefas e sua granularidade.

Não adianta usar os melhores comandos mas ficar 2 semanas sem abrir a PR, gerando um distanciamento enorme entre as versões!

É isso! Valeu! :)

Construindo do zero um backend NodeJS com NestJS + Design Patterns - parte um (1/3)

Rogério dos Santos Fernandes — Sat, 02 May 2020 01:00:56 +0000

Olá humano!

Co-escrevo esse artigo em meio a quarentena do Coronavírus com meu amigo e colega Matheus Viana (https://www.linkedin.com/in/matheusviana/). Na verdade, se trata de uma série de artigos que planejamos fazer para mostrar um Backend feito em NodeJS tendo em mente boas práticas de desenvolvimento ágil de software.

Neste primeiro artigo, vamos discutir sobre o que nos levou a escrevê-lo em primeiro lugar, e quais diretrizes nos guiam por essa jornada.

Motivação:

Trabalho com Node há cerca de 5 anos, e adoro a comunidade e a linguagem JavaScript e seu superset TypeScript. Existem inúmeras (de verdade!) formas de se construir um backend em Node, por isso quero focar aqui mais nos conceitos do que nas ferramentas, pois os conceitos e o valor que eles agregam são mais importantes, e são independentes de bibliotecas e frameworks!

Dito isso, o que queríamos atingir aqui é a construção de um Backend com esses requisitos em mente:

Seguir Padrões de Projeto e boas práticas reconhecidamente eficientes nos projetos empresariais, como:

Domain Driven Design
S.O.L.I.D.
Clean Code
DRY (Não se repita, em tradução livre)

Estes princípios e padrões acima nos norteiam na organização de nosso código, visando principalmente um código que possa escalar e não perca sua clareza, que fique se mantenha, ao longo do tempo, limpo e eficiente.

Partimos da visão de que escrevemos código para outras pessoas lerem, e não somente para máquinas.

Dito isso, vamos lá!

Partimos com o NestJS por ele ser um framework que já nos dá algumas coisas de prontidão, como:

Injeção de dependências
TypeScript
Testes de unidade e integração com o Jest!

Começamos a partir do próprio template do Nest, que também provê uma interface de linha de comando (CLI) bem útil:

// instala globalmente a CLI do Nest
npm i -g @nestjs/cli

// cria uma nova aplicação Nest com nome geekLounge
nest new geekLounge

após isso, editamos o README pra refletir a descrição do nosso projeto, um backend de um site de críticas de filmes chamado Geek Lounge. Definimos este contexto para podermos trabalhar em um domínio rico durante os artigos.

Foi incluído um passo antes dos commits que executam os testes de unidade e integração, a fim de manter a qualidade do código a cada commit!

yarn add -D husky

Assim, damos um ponto de partida pra essa jornada, e começamos nossa API.

Pra quem veio esperando ver muito código nesse primeiro post, peço paciência rs começamos pensando NO QUE queremos construir e PORQUÊ, que pra mim é o mais importante, pra aí então pensarmos no COMO!

Também configuramos uma esteira no Travis CI para todo o processo rolar com TDD e Continuous Integration.

Aqui está o link pro projeto: https://github.com/moviandev/geekLounge

Acompanhe-nos nas redes sociais pra receber as próximas postagens!

github: @dontpanicroger
twitter: @lifeaholicroger

Safe navigation operator coming to JS/TS

Rogério dos Santos Fernandes — Sat, 10 Aug 2019 13:21:37 +0000

Whatever you do, do it with love. I really like to apply this when I'm coding. Think that the code that you write will be the code that someone will read later.

In this post, let's discuss a little bit about validations against objects that can be null at runtime on JS and TS.

We need to do that to assert the response that came from an Http Request:

if (response.data && response.data.result)
  return response.data.result.map(mapFunction());

to validate that certain function parameter was passed into correctly:

function onSuccess(response) {
  if (!response || (response && !response.data))
    return new Error(`Hmm, where's my param?`);

  // else, do something
}

or to access some property in a model that have nested data like this:

if(account && account.role && account.role.permission)
  account.role.permission.ToString();

Deal with this can lead to code that is difficult to read, to test and to maintain.

Some actions can help a lot with that, like a shared layer (like an Http client wrapper) that deals with Http error codes and reduce the number of validations on your components and modules.

A concise API Design, to help your clients to deal with your data. A bad API Design can really do harm to your clients code! Try to avoid several levels of data, have a clear contract, a resource should only have one contract, a different contract should lead to a different resource. If you're doing microservices, GraphQL may be a good option. TypeScript already helps by telling at development time if something can be null.

That said, a language-level feature to help with that is really good! And we have good news! Just a few days ago, the Safe Navigator feature has gone to Stage 3, and to the TS 3.7.0 roadmap!

When this rollout, we will be able to do:

return response.data?.result?.map(mapFunction());
// undefined if something is undefined/null or the method result

if(!data.result?.length) return new Error('Hmm, still not getting it');

account.role?.permission?.ToString();

I believe this will help us create a smaller and more readable code. Angular 2+ already have that on the Html side, with the Template Syntax feature.

Despite this being a great addition to a fast-evolving language such as JS, is important to notice that you have other actions to improve the overall quality of your code.

Next steps...

Now, we can follow on Github the implementation of that feature.

The TC39 group makes a great job to make sure that JavaScript keeps evolving and became an even more consistent and strong language each year. TypeScript follows along, helping and giving us a great option in the JS ecosystem.

If you want to know more about the process of new features coming to JS/TS, give a look at these links:

TC39 Github
TC39 process

Operador de navegação segura vindo para JS/TS

Rogério dos Santos Fernandes — Sun, 04 Aug 2019 22:00:07 +0000

O que você fizer, faça com amor. Eu gosto de aplicar isso ao meu código. Pense que o código que você escreve será o código que alguém irá ler mais tarde.

Nesse post, discutiremos um pouco sobre validações em objetos que podem ser nulos na hora da execução do código (runtime).

Precisamos fazer isso para validar o retorno que veio de uma Requisição Http:

if (response.data && response.data.result)
  return response.data.result.map(mapFunction());

pra validar que os paramêtros da nossa função foram passados corretamente:

function onSuccess(response) {
  if (!response || (response && !response.data))
    return new Error(`Hmm, where's my param?`);

  // else, do something
}

ou pra acessar algum dado em um modelo com diversos níveis aninhados:

if(account && account.role && account.role.permission)
  account.role.permission.ToString();

Lidar com isso pode gerar código de difícil leitura, testabilidade e manutenabilidade.

Algumas ações podem ajudar bastante, como uma camada compartilhada (um encapsulador das comunicações Http, por exemplo) que lida com erros http e diminui a quantidade de validaçõe que você terá que fazer nos seus componentes e módulos.

Um Design de API conciso, para ajudar seus consumidores a lidar com seus dados. Uma API com uma estrutura ruim pode prejudicar bastante o código de seus clientes! Tente evitar muitos níveis diferentes para acessar alguma informação, tenha um contrato bem claro, um recurso deve ter apenas um contrato, diferente estrutura deveria levar a um recurso novo. Se você está fazendo micro serviços, GraphQL pode ser bom pra você. TypeScript pode ajudar dizendo o que pode ser nulo durante o desenvolvimento.

Dito isso, uma boa maneira de lidar com isso a nível de linguagem é muito bem vindo! E temos boas novas! Há alguns dias atrás, o Operador de navegação segura passou pro estágio 3, entrando no roadmap pro TS 3.7.0!

Quando isso for lançado, poderemos fazer:

return response.data?.result?.map(mapFunction());
// undefined if something is undefined/null or the method result

if(!data.result?.length) return new Error('Hmm, still not getting it');

account.role?.permission?.ToString();

Acredito que isso irá nos ajudar a escrever códigos menores e mais legíveis. Angular 2+ já provê isso do lado Html através do Template Syntax.

Apesar de ser uma ótima adição para uma linguagem que vêm evoluindo rápido como o JS, é importante notar que temos outras ações que devem ser tomadas para garantir a qualidade do nosso código.

Próximos passos..

Agora, podemos acompanhar a implementação dessa funcionalidade no Github.

O grupo TC39 faz um ótimo trabalho garantindo que o JavaScript continue evoluindo e se tornando cada vez mais uma linguagem consistente e forte. TypeScript vêm junto, nos dando uma ótima opção dentro desse ecosistema.

Se você quer ficar por dentro das novas funcionalidades vindo aí no JS e TS, recomendo que leia os artigos abaixo!

TC39 Github
TC39 process