Executando verificação de segurança...
32

Boas praticas no js que utilizo no dia a dia

Salve galera, meu nome é Vinicius e comecei a trabalhar como dev em 2018.

Esse é meu primeiro post da vida, não gosto muito de me expor estou tentando mudar isso com o tempo, porém como aqui ta sendo um ambiente bem legal, resolvi trazer um pouco de boas praticas que utilizo no meu dia a dia.

1 - Função com três ou mais parâmetros, eu prefiro passar um objeto.

Quando tenho que desenvolver uma função com três ou mais parâmetros fica um pouco trabalhoso de passar os parâmetros para a função e quando não é uma função que eu desenvolvi, porém preciso utilizar necessito voltar na declaração da função para saber oque é necessario passar em cada campo.

Exemplo de uma função com mais que três parâmetros:

montaNota

No momento que chamamos a função se somos o criador da função fica até facil de lembrar, porém os valores ficam soltos e é necessario ir direto na declaração da função para saber oque é necessario passar em cada campo.

Como essa função ultrapassa os três parâmetros podemos refatorar usando um objeto.

Exemplo de como é fazer a chamada da função sendo que os parâmetros estão em um objeto:

montaNotaMelhorado

Sim! Parece que escrevemos mais! Porém tem algumas vantagens…

Parece que o codigo esta mais verboso só que temos algumas vantagens que vou listar.

  • Primeiro que temos um tipo encapsulado do nosso metodo que podemos reutilizar em alguns outros locais.
  • A ordem dos valores agora tanto faz na invocação e fica bem mais facil de saber quais parâmetros são necessarios sem precisar ver a declaração da função, diminuindo o esforço cognitivo em futuras manutenções.
  • Legibilidade, quando alguem olha para a invocação da função imediatamente consegue identificar os parâmetros usados.

2 - Programação funcional > programação imperativa 😲

Estou brincando, na verdade seria utilizar os artificios funcionais da linguagem quando for possivel.

Javascript é uma linguagem que não é funcional 100% porém podemos utilizar alguns artificios que ajuda na legibilidade e no nosso dia a dia.

Vou mostrar um exemplo de uma soma de valores feito de um modo imperativo.

Untitled

Essa carinha do for já é bem manjada porque aprendemos na faculdade, porém podemos fazer algo mais simples e que provavelmente vai melhorar o nosso desempenho e conhecimento de como podemos trabalhar com arrays no JS.

Untitled

esse acima é o reduce ele é um metodo para arrays no JS, em primeiro momento parece um pouco complicado porém com uma breve explicação da para entender, vamos a explicação.

const total = comandas.reduce((*acc*, *comanda*) => *acc* + *comanda*.valor, 0);

Como é um metodo funcional primeiramente ele recebe uma função que no javascript normalmente chamamos de função de callback, essa função recebe um acumulador (acc) e um campo da comanda, depois dessa função ele recebe o valor inicial do acumulador que é 0.

Logo em seguida a função de callback é rodada recebendo campo a campo do array alterando o acumulador pelo retorno da função do reduce que seria acc + comanda.valor e após passar em todos os campos do array executando a função e guardando o acumulador ele retorna oque foi acumulado para a variavel total

Além do reduce temos o map , flatMap, filter, find, sort, todos esses ajudam bastante no dia a dia e melhoram a legibilidade e diminui o esforço cognitivo no codigo.

3 - Não utilize ELSE!!

Okay isso pode ser um pouco complicado de inicio e vai necessitar um pouco que você exercite, não utilizar else é uma regra do object calisthenics e eu acho ela uma das mais legais entre as 9 regras descritas.

Sem o else você consegue diminuir o fluxo de condições do seu codigo e com isso diminui a complexidade, maior problema do else que eu vejo é que ele é TUDO que não for if, em certas ocasiões faz total sentido ter um else ,dependendo da regra de negocio pode ser necessario um else porém a maioria do tempo não precisariamos dele.

Uma tecnica legal é utilizar o early return, ele **consiste em sempre retornar o mais rapido possivel de um metodo, sempre saia rapido de dentro de um metodo.

Uma ideia que utilizo é verificar as possiveis condições como regra de negocio e erros no inicio e o “caminho feliz” fica no final.

Ta bom já expliquei o suficiente vamos ver um codigo para ficar mais claro.

Untitled

Este codigo acima verificamos se o valor é acima de 90 não cobramos frete e caso não seja maior que 90 cobraremos frete, porém podemos melhora-lo.

Untitled

Beleza, ficou um pouco mais limpo sem o else e conseguimos diminuir o esforço cognitivo de entender esse metodo, também diminuimos os fluxos que a aplicação pode seguir.

3.1 Early return são os amigos que fazemos pelo caminho.

O early return consiste em falhar rapido, ( ué oque significa isso ? ) valide os possiveis problemas antes do “caminho feliz” vamos direto ao codigo.

Untitled

Percebe que é até feio de olhar para um codigo desse ?

Nesse codigo verificamos se o cara gastou mais de 90 e se for franqueado não paga frete, porém se for franqueado paga o frete, e no else verificamos se o valor ta invalido e avisamos o usuario do valor invalido, caso esteja valido apenas cobra o frete normalmente.

Imagina para o nosso cerebro que utilizamos ele o dia todo, o esforço cognitivo que utilizamos para entender.

Podemos refatorar esse codigo pensando em uma regra do early return, falhar rapidamente, exemplo:

Untitled

Levamos a validação de campo invalido para o começo do metodo e retornamos o quanto antes o erro para o usuario e não precisamos entrar no codigo todo, porém podemos melhorar ainda mais as validações.

Untitled

Aqui fazemos as validações antes e deixamos o “caminho feliz” por ultimo, verificamos se o usuario é franqueado caso seja pula para o outro if e verifica se o valor é acima de 90 e não cobra o frete e caso não seja acima de 90 cobra o frete normalmente.

Não precisamos aninhar if algum e conseguimos manipular melhor as condições e nosso esforço para entender é bem menor.

4 - Substituindo os switchs do nosso codigo

No Javascript as vezes nos perdemos em fazer um switch/case ou até varios if que funcionam para verificar um valor constante e retornar algo, nesses casos podemos usar o object literal, não confunda com template literal.

Object literal nada mais é que um objeto javascript porém como tem a chave e valor do objeto podemos criar algumas “verificações” que facilitam e limpam bastante o codigo.

Exemplo com if

Untitled

Exemplo com switch/case

Untitled

Apenas um exemplo porém deu para perceber que são valores estaticos, sem validações e estamos fazendo um parser dos valores para outra informação.

Mesmo assim ficou um codigo estranho e complicado para pouca coisa que ele faz, fora a repetição de codigo e no caso do switch/case o erro de esquecer um break; é enorme.

Podemos trazer o object literals para nós ajudar nisso e melhorar a legibilidade do codigo, exemplo:

Untitled

Uau parece magica né, porém o oque fazemos é passar o tipo para o objeto e pela chave do campo ele retorna o valor e o valor padrão sera Visitante caso não tenha nenhum retorno.

Podemos ver que melhorou a legibilidade e também a manutenção desse codigo, é um codigo que pode escalar rapidamente apenas incluindo novos valores na variavel tiposDeUsuarios e não precisamos repetir codigo.

Acaba aqui 🤙

Espero ter agregado algum valor a nossa comunidade, escrevi as primeiras coisas que chegaram na minha cabeça e fiz alguns exemplos para ilustrar.

Se vocês tiverem boas praticas que sempre lembram de utilizar no dia a dia comenta que também quero saber.

Tamo junto galera. 🤓

Carregando publicação patrocinada...
4

Vou deixar uma dica interessante aqui, sobre o console.log

Quando temos algo do tipo:

const nome = "daniel"
console.log(nome)

A saída é apenas um "daniel". Mas se usarmos chaves dessa forma:

const nome = "daniel"
console.log({nome})

A saída vai ser:

{ nome: "daniel" }

isso é util quando usamos muitos console.log no código.

4

Vou recomendar este repositório como um style guide js, é uma referência das boas práticas do airbnb para js:

https://github.com/armoucar/javascript-style-guide

Lá tem boas praticas para uso de objetos, não utilização de palavras reservadas, performace...

Também achei um style guide do google referindo a java

https://google.github.io/styleguide/javaguide.html

E isso me deu mais vontade de estudar as boas práticas de bons times para a qualidade dos seus produtos.

To gostando deste pedacinho da internet.
Tá bem organizado.

1
1
2
1

Não tinha ouvido falar do CDD e ainda mais criado por brasileiros, achei super interessante.

Obrigado pela informação e complemento.

TMJ 🤝

2

Ta aí algo interessante de estudar. Venho do java e por onde passava era considerado o 'chatão dos códigos' por presar pelas boas práticas de programação. Obrigado pela contribuição!

1

Sempre tive um preconceito com Java, mas nesse ano to sendo obrigado a mergulhar nele por causa da facul. Às vezes eu acho meio burocratico, mas que a linguagem é muito bem organizada, ninguém pode reclamar.

1
0

Ou vc era o chatão por querer java em JS kkkk(isso acontece)

Java JS apesar dos nomes são linguagens muito diferentes.
E tem gente de linguagens como Java e C# que qerem impor o estilo antigo no
JS ai não dá, JS tem seu estilo e jeito de fazer as coisas!

1

Creio que tenha entendido errado, eu me refiria a minha experiência com java e não com Js. Apenas trouxe a comparação de perfil interessado em manter as boas práticas em cada nixo de linguágem. A propósito eu nunca trabalhei profissionalmente com Js, sempre com Java, logo não faz sentido o que mencionou.

2
1
1

Boas práticas mesmo 👍

O early return também é chamado de guard clause ou cláusula de segurança.

É importante dizer que as funções devem conter apenas aquilo que é necessário pra sua execução. Uma armadilha comum é aplicar uma programação defensiva, em que se checa condições mirabolantes tentando fazer com que o código não falhe mas poluindo a leitura. Determinar o escopo das condicionais ainda é uma arte dentro da programação.

1

Essa dica de não usar else e do early return é sensacional.
Este final de semana mesmo estava assistindo um vídeo a respeito de como o Linus Torvalds é contra o encadeamento de mais de três níveis de código e técnicas para evitar isso.

Evitar encadeamentos e utilizar early return juntos aumenta muito a qualidade do seu código. E te diferencia do chat gpt, diga-se de passagem.

Li esse artigo hoje pela manhã e passei imediatamente a aplicar as técnicas nos códigos que estou desenvolvendo.

1
1
1

Lendo esse post percebi que já ultilizo bastante de boas práticas, mas ainda assim tenho muito o que melhorar, percebi que só pensando na quantidade de passos que aplico para uma determinada fubção vejo se tem um caminho menor para fazer o mesmo, então naturalmente acabei desenvolvendo algumas dessas práticas. Adorei o conteúdo 👏👏

1

Ótimo artigo.
Direto ao ponto, com explicação super didática e extremamente útil.

Acredito que o early return e função com três ou mais parâmetros se tornarem um objeto são dicas quase que "obrigatórias" para um código cada vez mais limpo, legível, manutenível e adaptável a evoluções/mudanças.

1
1
1

Ótimas dicas, parabéns.
Gostei do Object Literals, só fiquei pensando em um ponto.
Se você precisar tomar decisões, com base nas informações que estão dentro do objeto TipoDeUsaruarios, precisaria de condicionais(if/else ou switch/case), certo?

2

Opa tudo certo ?

Além do valor estatico tem como passar funções para serem executadas caso bata com aquele valor da chave.

Exemplo:

const acoesDeAdmin = ()=> {
  alert("Sou admin")
}

const acoesDeUsuario = ()=> {
  alert("Sou usuario")
}

const acoesDeVisitante = ()=> {
  alert("Sou visitante")
}


const tipoDeUsuarios = {
  admin: acoesDeAdmin,
  user: acoesDeUsuario,
  visitante: acoesDeVisitante
}

const acaoUsuario = tipoDeUsuarios['admin'] || acoesDeVisitante

acaoUsuario()

Porém se for uma validação mais complexa que precise usar operadores logicos como AND(&&) e OR(||) ou até mesmo comparar se é maior ou menor que algo, eu prefiro usar if acho que fica mais legal.

Ah tem esse video do Deschamps https://www.youtube.com/watch?v=Lf3ZV0UsnEo&ab_channel=FilipeDeschamps
que é muito bom e pode ilustrar melhor.

Valeu.

1
1
1

Hoje quando estava programando percebi que boa parte do tempo que perco é tentando entender o código que escrevi, justamente por conta da bagunça e falta de boas práticas.
Seu post caiu como uma luva, obrigado por contribuir bro! 👏🏽👏🏽

1
1

Olá @viniielopes tudo bem? Percebi que na última imagem da sessão 3.1 tem um erro no código. Está faltando um return; depois do naoCobrarFrete na linha 14.

E obrigado por compartilhar suas dicas.

1

Opa @Fagner tudo certo e com vc ? putz quando estava escrevendo o exemplo acabei não reparando e passou.

Obrigado por ter reparado nesse erro, ajustei com o return; que vc citou.
Valeu demais.

1
1
1

Estou no mercado há quase 2 anos e não conhecia ainda esse Early Return. Com certeza vou adotar o mesmo no meu dia-a-dia a partir de agora. Parabéns pelo artigo!!

1

Outra vantagem de usar o objeto nos parametros é quando você não precisa de tudo do parametro, assim pode desestruturar só o necessário.

1