Este post é o primeiro de uma série interessante de posts que se aprofundarão no bem conhecido tópico do “Clean Code”, mas aplicado ao JavaScript.
Nesta série, discutiremos as dicas clássicas sobre Clean Code (código limpo) que todo/a programador/a deve saber, aplicado a uma linguagem JavaScript/TypeScript específica.
Introdução
A primeira coisa a fazer é passar pelos conceitos do Clean Code:
1. Code smell e Refatoração
“O Code Smell é uma indicação que geralmente corresponde a um problema mais profundo no sistema.”
— Martin Fowler
“Code Smells ruins podem ser um indicador de fatores que contribuem para um débito técnico.“
— Robert C. Martin
Na minha opinião, as definições de Martin Fowler e Robert C. Martin são compatíveis porque a definição de Fowler indica uma pista para um problema de software, enquanto a definição de Martin se refere a um efeito colateral causado por Code Smells.
2. Outro termo interessante é Débito Técnico (Technical debt)
Débito Técnico é um conceito no desenvolvimento de software que reflete o custo implícito do retrabalho causado pela escolha de uma solução mais fácil ao invés de usar uma abordagem melhor, mas que levaria mais tempo.
Portanto, como na própria vida, o ideal é não ter débitos, mas para isso precisamos ter uma economia saudável (programadores/as experientes e infraestrutura que permita desenvolvimentos sem consequências negativas).
No entanto, às vezes precisamos de um empréstimo para fazer a faculdade ou para comprar nosso primeiro carro. Provavelmente, temos essa dívida sob controle e pagamos pouco a pouco.
No software, deve ser exatamente o mesmo, devemos contrair as dívidas que poderemos pagar mais tarde.
Nenhum de nós pensaria em comprar uma casa de vários milhões de reais sem ter uma poupança ou um emprego, esses são os débitos que nos levam a falhas no software.
Portanto, a refatoração de código é o processo de reestruturação do código de computador existente, sem alterar seu comportamento externo.
- A refatoração aprimora atributos não funcionais do software.
- As vantagens incluem melhor legibilidade do código e complexidade reduzida.
- Isso pode melhorar a manutenção do código-fonte.
- Cria uma arquitetura interna mais expressiva para melhorar a extensibilidade.
Clean Code: antes de começar
Antes de começar a ver exemplos de Clean Code em JavaScript, é muito importante algumas recomendações essenciais para o trabalho em equipe.
Legível para Humanos
O código deve ser legível para humanos.
Não pense em como será processado pelo computador, pois haverá muitas ferramentas que transformarão nosso código (transpiladores).
Portanto, o mais importante é que o código seja legível para humanos, porque a parte mais longa do seu trabalho quando você estiver desenvolvendo um código será ler o código, em vez de escrevê-lo.
Abaixo, há três exemplos da mesma matriz de usuários.
Qual é o mais legível? Qual deles exige menos esforço intelectual para fazer a leitura? Bem, é assim que você deve estruturar seu código.
Desenvolver em inglês
Na verdade, eu não sou um falante nativo de inglês e meu grande problema nessa indústria é que mal consigo ter boas e interessantes conversas em inglês, em comparação com a minha língua nativa.
No entanto, nas aulas, eu transmito para meus/minhas alunos/as que eles/as devem escrever o código em inglês e, consequentemente, todo o meu código é desenvolvido em inglês.
É melhor usar um inglês ruim do que a sua língua materna, a menos que você tenha a sorte de ser um falante de inglês.
A razão para isso é que o inglês é usado para negócios no mundo todo.
Você pode gostar ou não, mas todos no mundo entendem que o inglês é o idioma a ser usado ao interagir com outro país e, como eu disse antes, na maioria das vezes você lerá o código.
Imagine ler o código em um idioma no qual você não será capaz de compreender as variáveis ou o nome da função; todo o código será criptografado para você.
Portanto, você deve desenvolver em inglês, mesmo que não seja seu idioma nativo. Vamos aprender inglês enquanto trabalhamos.
De qualquer forma, pense em mim: eu não sou nativo, mas todos os dias leio e escrevo em inglês, é claro que com erros, mas todos nós devemos ser compreensivos uns com os outros, porque o importante ao usar um idioma é garantir que o significado fique claro.
Tente deduzir o que o seguinte snippet de código faz, algo que seria muito básico no seu idioma.
O seguinte snippet de código está em idiomas diferentes e em inglês (obviamente, se um dos idiomas do exemplo for o seu nativo, você entenderá).
De qualquer forma, se você for um poliglota, acesse o Google Tradutor e coloque o código em outro idioma que você não conheça e tente deduzir o que o código faz.
Trabalho em equipe
Era uma vez um/a programador/a que desenvolvia o projeto de um software. Que história bonita!
Essa é a forma que todos nós aprendemos a programar, sozinhos.
Encaramos um computador, digitando os códigos e resolvendo problemas. Mas, hoje, ninguém desenvolve um software só.
Portanto, temos que pensar em trabalhar em equipe.
Discussões eternas entre programadores/as juniores:
- Tabule usando espaço ou tabulação.
- Abra as teclas ao lado do nome da função ou numa linha inferior.
- Coloque um ponto e vírgula no final de uma frase.
Como esses argumentos soam para você? “Desculpe, essas discussões são absurdas” porque essas decisões são acordadas entre todas as pessoas da equipe e, em seguida, são usadas ferramentas de desenvolvimento que modificam o código e o normalizam para todos/as.
Uma equipe de devs é integrada no momento em que um/a programador/a abre um arquivo de projeto e começa a ler o código e não consegue deduzir se esse código foi programado por ele/a ou por um colega de equipe.
Este é o ponto perfeito de uma equipe de desenvolvimento, nos tornamos grandes programadores/as trabalhando juntos/as.
Lembre-se que, se precisarmos saber quem escreveu algo do código, temos ferramentas poderosas, como o GIT.
Portanto, para trabalhar diretamente em equipe, precisamos:
Não ser obrigados/as a usar um IDE específico, para isso existe o .editorconfig padrão que permite que cada membro da equipe trabalhe com seu IDE perfeito.
Cada pessoa é um mundo, e nem todos devem usar WebStorm, VSCode ou Eclipse, porque alguém decidiu por um padrão que nos permite configurar elementos básicos de estruturação, como o padrão .editorconfig.
O .editorconfig ajuda desenvolvedores/as a definir e manter estilos de codificação consistentes entre diferentes editores e IDEs.
O Lint nos permite encontrar erros na formatação do código com base em algumas regras que estabelecemos, e cada idioma possui seu próprio Lint, procure na sua linguagem de desenvolvimento e você deve configurá-las e usá-las.
Os acordos são os mesmos, às vezes haverá projetos nos quais o código não é feito como você gosta, mas pelo menos você pode continuar digitando dessa maneira e delegar ao IDE a pessoa encarregada de alterá-lo, para que não represente um problema para você na hora de gerar o código.
Existe uma ferramenta amplamente usada na indústria, conhecida como Prettier, que permite alterar a formatação do nosso código em tempo real (plugins dos IDEs), com base nas regras do Linter.
Isso nos permite focar no problema que temos que resolver e, além disso, estaremos gerando um código limpo, sendo uma equipe unida.
Conclusões
Neste post, resumimos vários pontos fundamentais antes de tentar abordar práticas e recomendações de código limpo (Clean Code).
Os princípios que discutimos são gerais para qualquer desenvolvedor/a:
- Escreva códigos legíveis para humanos e não para máquinas. Na maioria das vezes, você lê códigos, tanto os seus quanto os de seus parceiros.
- Escreva em Inglês. Hoje é o idioma internacional e nós temos que ser internacionais, porque dessa maneira podemos compartilhar códigos com qualquer pessoa no mundo.
- Trabalhe em equipe. Crie regras comuns e conte com ferramentas que permitam gerar o código uniformemente para todos. Você precisa chegar ao ponto em que todo o projeto parece programado por uma única pessoa, em vez de observar os diferentes costumes dos vários membros da equipe de desenvolvimento.
Este é um artigo traduzido, você pode acessar a versão original em inglês aqui. Todos os créditos para o autor: Carlos Caballero
Last modified: 01/07/2020