Qualidade de código no frontend

Achou que não ia ter mais post meu esse ano? Achou errado… E hoje iremos abordar um assunto muito polêmico: qualidade de código. Este assunto nunca esteve tão evidente em toda minha carreira como Dev, como esteve este ano, e acredito fortemente que é um tópico muito negligenciado enquanto estamos desenvolvendo nossas hard skills, principalmente no frontend.

Rogerinho do Ingá preocupado com seu código cheio de gambiarras.

Qualidade é o que mesmo?

É muito complexo dizer que existe uma fórmula mágica que vai indicar se o código tem qualidade ou não, cada time ou projeto deve ter bem definido as boas práticas PARA AQUELE MOMENTO/PROJETO, antes mesmo de começar, porque cada desenvolvedor tem a sua forma de escrever código, MAS, existem conceitos que se não seguirmos, certamente teremos problemas no futuro.

Sabe quando você vai dar manutenção num código que não é seu e você pensa em mudar de profissão de tão ruim que está a coisa? Então, se você preocupar com qualidade, você nunca vai passar esse sentimento adiante.

Legibilidade

Acredito que este é o primeiro ponto, o primeiro dedo na ferida, porque muitos problemas surgem da falta de legibilidade do código, diversas vezes por não entendermos o que determinado trecho está fazendo, acabamos reproduzindo algo que já existe, ou gerando algum retrabalho e com isso só aumentamos os problemas futuros. Imagine a seguinte situação:

Dev A está trabalhando numa funcionalidade de modal, e escreve um código ilegível, o modal funciona mas ninguém além dele sabe dar manutenção naquele monstro, de repente o Dev A não está mais no projeto e o Dev B é alocado, logo ele está trabalhando num modal mais complexo para uma nova funcionalidade, como ele não entende o código anterior ele cria um novo modal com as novas funcionalidades.

Percebam que neste exemplo temos dois trechos de código fazendo praticamente a mesma coisa, isto aumenta a manutenção no futuro além de comprometer muito a estrutura do projeto, imagina fazer testes então einh. Então um código legível deve:

• Ter se possível poucas linhas, sim isso pode parecer idiota mas quanto menos você precisa ler, mais você consegue entender o que o código faz, outra questão é que se uma classe/função faz muita coisa, é um sintoma que algo está errado(falaremos disso melhor lá na frente).
• Ter declarações expressivas, ou seja, os nomes das classes, constantes e funções devem expressar o que elas fazem ou representam, se o nome da função for calculaIdade ela tem que CALCULAR A IDADE;
• Ser LEGÍVEL, parece redundância mas, escrever código que a máquina entenda é muito fácil, mas escrever código que outra pessoa entenda, isso sim é a magia, e este conceito pode sobrepujar o primeiro citado, porque se escrever mais linhas de código vai deixar ele mais legível, então escreva, não há problema algum nisso.
• Ser organizado, desde a estrutura até a nomenclatura, um bom exemplo disso é deixar que a ordem da leitura do código siga a ordem de execução ou construção da lógica do que ele faz.

A ordem de leitura desse código já nos mostra exatamente o fluxo que ele mesmo segue, além de deixarmos claro usando a tipagem do Typescript. É estranho ver o método de render antes das funções, mas se observarmos, as funções utilizadas dentro do render, são chamadas depois da chamada do método render em si.

Criar interfaces é uma ótima prática para a legibilidade, porque nos indica muito claramente o que esperar de determinado código, seja constante ou classe, esta é uma funcionalidade muito massa do TS, e caso você queira saber um pouco mais, segue aí um outro post falando de TS e React.

Manutenibilidade

“Essa palavra nem existe” — Dev que joga o bug pra outra pessoa resolver. Bom essa palavra existe sim, e para mim manutenibilidade envolve três principais caracteristicas:

A capacidade de um código se manter estável: não adianta fazer um monte de coisas se manter elas vai ser uma tarefa impraticável, e isso impacta em qualidade, imaginem uma montadora que monta carros cuja manutenção é impossível. Esta estabilidade está mais ligada a soma dos fatores que vão de arquitetura ao código em si, por exemplo, uma classe que tem muitas responsabilidades com um código ilegível se torna muito INSTÁVEL.

A flexibilidade do código: trabalhar com React ou com qualquer outra lib que segue os mesmos paradigmas nos dá poderes para criarmos as coisas como bem queremos, e com grandes poderes, vem grandes dores de cabeça, e grandes responsabilidades também, um código flexível implica em criar coisas extensíveis para novas funcionalidades que expressem a “razão” daquele código, por exemplo, diferentes tipos de botões compartilham entre si um mesmo comportamento: um clique para executar ou não uma ação, eu diria que essa é a razão do botão, mas quando criamos um, devemos pensar que ele precisa ser flexível o suficiente para assumir as mais diversas formas, cores, tamanhos, etc.

O Ispáider encontrou 8 classes que fazem a mesma coisa no código.

A repetibilidade do código: volta e meia durante o processo de desenvolvimento, estamos repetindo comportamentos, como o exemplo acima do botão, repetimos em diversas partes de uma aplicação os mesmos componentes, então aquele principio do reuso que vemos quando lemos sobre React entra nesse ponto, porque repetir é entregar sempre a mesma coisa, ou seja, eu não posso obter um comportamento diferente de determinada classe só porque ela foi usada num escopo diferente. Juntamente com a Flexibilidade, a Repetibilidade evita muito código duplicado, mas notem que são coisas distintas, uma delas envolve estender comportamento, a outra envolve repetir comportamento.

Utilize padrões de design

O frontend é dinâmico mas não é bagunça, os padrões em si são conjuntos de melhores práticas para resolver problemas recorrentes, o próprio conceito “core” do React é um padrão, que é a composição, ele permite que os componentes maiores sejam construídos a partir da composição de componentes menores. Existem diversos padrões, eles não estão ligados a uma linguagem em si mas sim no conceito de desenvolvimento, é comum vermos com mais frequência em linguagens como Java ou C, mas não se enganem, saber escrever um bom código é mais importante do que escreve-lo rápido.

No dia a dia do frontend nos preocupamos muito com UI/UX e fluxo de dados, e por vezes negligenciamos a questão da qualidade, e isto é comum porque o frontend é muito mais “tangivel” do que outras coisas, estamos comumente muito mais preocupados em ver a coisa pronta e bonita do que em entender como foi feita, logo temos por aí muito mais conteúdos ensinando funcionalidades de React/Angular/Vue/Whatever do que conteúdos focados em paradigmas de desenvolvimento, pensando nisso preparei uma lista com tópicos que vão auxiliar a virar essa chave do desenvolvimento com qualidade.

• S, O e I do SOLID (Single responsability, Open/Closed principle e Interfaces)
• Abstração
• Composição
• Factory
• HOC (High Order Components)
• Como funciona o setState do React (parece idiota mas vai por mim, É IMPORTANTE)
• Bundle size após o build no React (isso aqui vai impedir sua node_modules de pesar mais do que um hello world em Java, piada velha mas boa)
• Singleton

Seu código novo e com qualidade destruindo aquele código lixo que você fez sem pensar no amanhã.

Escreva testes

Acho que nem precisamos frisar o quão importante é um código testado, deixei esse tópico por último justamente por não ter muito o que discutir a respeito, existem diversas maneiras de escrever testes, e diversas metodologias, mas uma coisa é certa, os testes salvam sua vida. Obviamente existe um custo de tempo de desenvolvimento quando falamos de escrever testes, mas a solidez e confiabilidade do código se tornam maiores quando realizamos essa etapa, então pensem bem sobre isso.

Chegamos ao fim do post, e com isso quero dar uma ênfase novamente que qualidade de código existe no frontend e ela não deve ser negligenciada, este sentimento do código bom, vem com o tempo, mas ele não vai surgir se você não começar a aplicar as coisas. Criar coisas é muito legal, mas criar coisas robustas é mais legal ainda. Vejo vocês por aí…