Meu Controle De Qualidade Para Projetos Serverless Com Node.js

Mateus Malaquias
Mar 29, 2019 · 8 min read
Image for post
Image for post

Com quase um ano trabalhando com Serverless, Node.js e JavaScript pude perceber o quão flexível essa stack é! Também pude perceber como o estilo de escrever código de cada pessoa que participa do projeto pode deixar a manutenibilidade do mesmo um caos.

Estudando um pouco e perguntando na comunidade acabei encontrando um leque de ferramentas muito versáteis. Com a ajuda do ESLint, Prettier e Jest, estamos conseguindo garantir uma boa qualidade de código por aqui.

No artigo de hoje quero compartilhar com vocês um pouco de informação a respeito dessas ferramentas e quais regras utilizamos no meu time, provavelmente para a maioria das aplicações essas regras podem ser “too much”.

Mas trabalhando no dia a dia com APIs de alto desempenho e com baixo uso de memória, elas estão ajudando e muito a nossa caminhada.

Vamos primeiro falar sobre o básico.

O que é um guia de estilo e por que preciso de um?

Um guia de estilo é basicamente um conjunto de regras que irão definir como o seu código será escrito e organizado. Isso se torna muito útil quando uma nova pessoa entra no time ou quando vamos dar manutenção.

No contexto de negócio a sua empresa provavelmente não se importa com isso, mas por que você precisa de um?

Vamos imaginar um cenário onde temos três pessoas desenvolvedoras: Fulano, Beltrana e Ciclana. Cada uma dessas pessoas gosta de escrever código de uma maneira diferente, ou seja, Beltrana prefere usar tab para espaçamento, enquanto Fulano e Ciclana preferem espaços, Beltrana prefere usar ponto e vírgula, Ciclana prefere usar arquivos com poucas linhas de código e por aí vai…

Agora imagine o caos que seria se somente Beltrana usasse ponto e vírgula e tab? Se somente Ciclana tivesse arquivos pequenos?

Com a nossa aplicação crescendo as coisas podem ficar confusas muito rapidamente. É aí que os guias de estilo são muito úteis. No passado, pesquisei dois guias de estilo, vamos dar uma olhada neles e depois explicarei como criei uma extensão de algumas regras.

JavaScript Standard Style Guide

É de longe o mais usado! Talvez pelo fato de prometerem “Zero configurações a realizar. Nenhum arquivo .eslintrc, .jshintrc ou .jscsrc para gerenciar. Apenas funciona”.

Por ser usado em muitos projetos open source, recomendo que leia sobre as regras deste guia no seu site.

Airbnb JavaScript Style Guide

Outro estilo de código bastante utilizado (atualmente uso ele), foi criado pelo Airbnb. Eles cobrem quase todos os aspectos do JavaScript e contém todas as regras de ESLint usadas nos produtos da Airbnb.

Recomendo que você explore o guia no GitHub.

Conhecendo um pouco do ferramental

Estlint

O ESLint é uma ferramenta maravilhosa que analisa o seu código e sinaliza problemas encontrados de acordo com a configuração utilizada por você. Com ele é possível encontrar bugs, códigos muito complexos e até estilos de codificação que não foram atendidos.

Sua instalação e configuração é bem simples, não vou explicar esse processo então recomendo ler esse texto do Lucas Ferreira.

Prettier

O Prettier é simplesmente um formatador de JavaScript. Projetado por James Long, ele suporta linguagens como JavaScript (ES8 incluído), TypeScript, JSX, Fluxo, JSON, GraphQL e até mesmo CSS.

Não encontrei uma leitura em português, mas essa em inglês escrito pelo Raphael Ugwu está muito boa.

Jest

Jest é uma biblioteca desenvolvida pelo Facebook que fornece uma estrutura completa para desenvolvimento de testes de todos os níveis (unitário, integração e por aí vai).

O Guilherme Cabrini da Silva escreveu um artigo muito bom para quem está começando, recomendo leitura também.

Para resumir ainda melhor o uso de todas essas ferramentas, recomendo esse vídeo da galera do RocketSeat.

Agora vamos ao que interessa!

As minhas regras

Muitas das regras que uso são personalizadas em cima das regras do Airbnb, então validações como variáveis não sendo usadas, chaves duplicadas, aspas duplas tudo isso está sendo validado pelo Airbnb. Me atentei a personalizar poucas regras.

Regra 1: Complexidade

Essa regra tem o foco de reduzir a complexidade ciclomática do seu código, medindo a quantidade de ramificações que uma função possui. Imagine uma ramificação como um caminho que seu usuário vai percorrer para realizar determinada ação.

A Jakeliny Gracielly abordou esse assunto no 7Master, recomendo que assistir para entender melhor.

O time do Airbnb é decidiu desabilitar essa validação no ESLint, mas o meu time tem configurado o valor 5, logo o código abaixo vai retornar um aviso quando fizermos deploy.

Quanto menor for a complexidade ciclomática da sua função mais fácil ficará a manutenção da mesma.

Regra 2: Quantidade de instruções numa função

Funções devem ser curtas e concisas. Isso vai facilitar a leitura, a manutenção e a evitar bugs.

Com “max-statements” você vai especificar o número máximo de instruções permitido em uma função.

Logo o código abaixo vai retornar um aviso e uma futura refatoração será planejada.

Com “max-statements-per-line” estou limitando o número de instruções permitidas em uma única linha, porque muitas instruções na mesma linha também atrapalham.

Logo as declarações abaixo, por exemplo, nos enviaria um aviso.

Regra 3: Aninhamentos

Lembra do callback hell? Não é só ele que me preocupa, conseguimos criar “hell” para todo código possível de aninhamentos como, por exemplo: promises, loops e condicionais.

Então um código como o abaixo, por exemplo, não passaria:

Regra 4: Quantidade de parâmetros

Funções que possuem muitos parâmetros podem se tornar difíceis de ler, usar e manter. Porque elas vão requerer um entendimento melhor sobre cada parâmetro, tipo e a ordem de utilização.

Por padrão o ESLint segue a recomendação do Clean Code do Uncle Bob, todavia todas as regras que estou personalizando são sugestões de melhorias por isso ela entra na minha lista.

Esse é um assunto bastante controverso entre as pessoas desenvolvedoras, costumo pensar que se tivermos muitos parâmetros, é um sinal que a função está fazendo muitas coisas e não respeita o Princípio de Responsabilidade Única. Talvez existam um ou mais parâmetros que possam ser relacionados e transformados em um objeto.

Logo o código abaixo não vai funcionar:

Regra 5: Quantidade de linhas

Não concordo com o Uncle Bob nos mínimos detalhes, mas ele tem uma afirmação que não tenho como refutar:

If small is good, then smaller must be better — Uncle Bob

Com esse pensamento em mente podemos aplicar isso para nossas funções, classes, módulos, pacotes, ao infinito e além!

Poucas pessoas sentem o mau cheiro de código em arquivos muito grandes. Para mim arquivos grandes tendem a fazer muitas coisas, esse é outro sinal da quebra do Princípio de Responsabilidade Única.

Embora não exista um número máximo para o tamanho de um arquivo, acredito que a maioria das pessoas concorda comigo quando digo que variar entre 100 a 200 linhas é um ponto seguro.

Todavia no meu caso quanto menor a responsabilidade de um módulo node.js, mais fácil fica de solucionar um bug ou realizar uma refatoração, por isso o meu número máximo é tão baixo, quero desenvolver módulos especialistas em fazer um pedaço de um módulo maior.

Agora falando sobre o tamanho máximo de uma linha, sigo a recomendação do Douglas Crockford que ele escreveu no livro O Melhor Do JavaScript.

Regra 6: Reatribuição de parâmetros numa função

Salvo as exceções que estão listadas acima gosto de evitar ao máximo uma atribuição de valor para as variáveis declaradas como parâmetros de função porque dependendo do meu fluxo de negócio posso cair em um comportamento confuso, já que modificar parâmetros de função também irá alterar o objeto passado como argumento.

Na prática, acredito que os efeitos colaterais nos parâmetros podem causar um fluxo de execução contra intuitivo e dificultar a localização de erros.

Reunindo todas as regras

.prettierrc

.editorconfig

Não tenho muito o que falar sobre essas regras, elas são usadas apenas para automatizar o processo de formatar o código.

Nos meus projetos serverless não escrevo testes de integração porque eles vão me gerar um custo desnecessário para o que eu preciso, me atento a fazer somente testes unitários com a maior cobertura possível que hoje gira em torno de 90%.

Se você está começando com testes ou não tem o costume de escrever testes e vai começar a desenvolver um projeto serverless os seus testes no final do dia vão ser seus melhores amigos.

Recomendo que você mantenha a sua cobertura acima do que se costuma recomendar (70%), no começo vai parecer um saco ficar escrevendo tanto teste, mas com a medida que a sua aplicação for crescendo/mudando e os erros forem aparecendo você vai perceber que os testes vão te ajudar a enxergar o problema e muitas das vezes vão servir como uma documentação do seu código por isso escreva boas descrições.

Por isso recomendo que você leia esses dois artigos do Lucas Santos:

Outra coisa que ajudam e muito na criação de testes unitários é uma boa injeção de dependências, o Vinicius Reis tem um artigo excelente sobre isso:

Conclusão

O peso da qualidade do seu projeto é relativamente proporcional a qualidade dos seus testes e do código que você aplica.

Se quiser entrar em contato comigo estou sempre caminhando pelo Twitter e Telegram

Originally published at malaquias.dev on March 29, 2019.

CollabCode

Aqui é o ponto de encontro entre quem quer aprender e quem…

Mateus Malaquias

Written by

Baiano | Software Development Engineer | I’m a back-end developer who like to work and collaborate with teams and also have good interpersonal skills.

CollabCode

Aqui é o ponto de encontro entre quem quer aprender e quem pode ensinar, de forma colaborativa.

Mateus Malaquias

Written by

Baiano | Software Development Engineer | I’m a back-end developer who like to work and collaborate with teams and also have good interpersonal skills.

CollabCode

Aqui é o ponto de encontro entre quem quer aprender e quem pode ensinar, de forma colaborativa.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store