Independente de quanta experiência você tenha, seja estudando, trabalhando ou até mesmo sendo hoje seu dia zero na programação, com quase 100% de certeza você já ouviu ou vai ouvir sobre Clean Code e quando esse momento chegar, sinta-se feliz.
Na minha humilde opinião, esse é o tema que consegue dividir com muita facilidade os bons dos maus programadores e programadoras; não que essa divisão seja uma necessidade prioritária ou de extrema importância, mas ela é essencial para quando você empacar nos estudos.
Nesse texto, não vou te ensinar sobre clean code e nem “como aplicar clean code agora mesmo no seu código em 5 passos”, mas sim explicar um pouco do que NÃO É clean code e sobre alguns mitos que vejo espalhados por aí.
Em 2021 era bem comum ver publicações no LinkedIn sobre kits que pessoas recebiam ao entrar em alguma empresa; entre mochilas, copos plásticos e mousepads, achava-se com bastante facilidade o livro Clean Code lançado em 2008 e escrito por Robert Cecil Martin - Uncle Bob.
Isso é algo interessante pois a gente pode se perguntar:
“Porque eu ganhei isso da empresa?”
E a resposta é bem simples - mas não simplória:
Eles querem que o seu código tenha qualidade.
E aqui surge o ponto principal de toda discussão em torno de Clean Code.
Qualidade!
Por mais que todo mundo saiba o que é qualidade, ninguém consegue defini-la com algum grau alto de certeza, até porque quando se fala de código, construção de software e usuários, a palavra “qualidade” passa por várias transformações e significados diferentes..
O que é qualidade em um software?
O programador ou programadora provavelmente dirá que é um código com boa legibilidade, já para gestores de projetos velocidade em manutenção e adição de novas features é a resposta correta, entre CEOs pode ser um software que tenha um baixo custo por bugs, mas para o cliente pode ser uma paleta de cores bonita ou uma aplicação que não trave.
Portanto, qualidade pode ser uma ou várias coisas ao mesmo tempo, e todos que comentam sobre ela, estão corretos - em seus respectivos espaços.
Um pouco confuso, não?! A partir disso, certezas sobre “qualidade” e “clean code” são fincadas na internet que acabam muito mais atrapalhando quem está começando do que trazendo respostas.
Por isso, separei 2 mitos que devem ser no mínimo tratados com ceticismo antes de comprar a camisa “Clean Code = código pequeno e rápido”.
Querida, encolhi as crianças (1989)
No finalzinho dos anos 80 o diretor Joe Johnson deu vida a um dos meus filmes preferidos que por muito tempo foi reprisado na tv aberta.
Um cientista, que não tinha muita coisa para fazer, resolveu testar um dos seus mais novos experimentos em seus dois filhos e como resultado, as crianças encolheram; e ao longo do filme você acompanha a jornada dessa família para trazer tudo de volta à normalidade.
Mas o que isso tem a ver com Clean Code?
Nas rodas de conversa sobre software é bem comum você ouvir coisas do tipo:
- “Clean Code é código pequeno”
- “Clean Code é só trocar os ifs e os laços por algum método mais moderno”
- “Se você reduziu 30 linhas do seu código, então ele está limpo”
Mas a verdade é que esses pontos estão muito mais errados do que certos, pois a redução de código é bem mais uma consequência de um código limpo do que de fato a definição própria dele.
Qualidade de código - falando exclusivamente da área de desenvolvimento - está diretamente ligada à legibilidade do código, ou seja, o quão fácil é para você e outras pessoas lerem e entenderem aquilo que foi escrito.
Vá por mim, o computador após receber as instruções binárias está pouco se lixando para a beleza do seu código, ele apenas vai executar o que lhe foi solicitado, portanto, você não escreve códigos para computadores, mas sim para outras pessoas, então é sua responsabilidade saber escrever um bom código.
Da uma olhada nesses códigos e me diga qual dos dois está mais legível:
Primeiro código:
for (let i = 0; i < 7; i++){
// Faça algo
}
Segundo código:
const diasDaSemana = 7;
for (let i = 0; i < diasDaSemana; i++){
// Faça algo
}
Olhando rápido, não parece ter diferença, certo? Até porque é um simples laço que deve executar algo até que a variável controladora de loops se torne falsa.
Agora faça um exercício de imaginação: você acabou de chegar em uma empresa nova, acabou de puxar o código para o seu computador e se depara com esse laço.
Observando o primeiro código provavelmente você vai parar alguns segundos e se perguntar, “Mas que diabos significa esse 7 aqui?” .
Você vai gastar um certo tempo tentando adivinhar seu significado, ou se ele está aí apenas por acaso - e muito provavelmente essa nunca vai ser uma opção válida. Em quanto tempo você finalmente entenderia que esse número simboliza os dias da semana?
Já no segundo código essa informação está extremamente explícita, um pouco maior - mesmo que seja apenas uma linha - e muito mais legível.
Agora passo para você a pergunta, qual dos dois códigos tem mais qualidade para desenvolvedores?
O tempo ganho nessa simples situação poderia ser convertido em adição de novas features, manutenção de outras partes do código, maior entendimento na resolução de bugs e um CPB (custo por bug) muito mais barato.
Portanto, um código limpo não significa diminuição de código.
Velozes e furiosos (2001)
Tenho um tio que não gosta de nenhum tipo de filme e ele afirma isso em cima de um argumento muito válido - para ele.
“Nada que passa nesses filmes é verdade, é tudo mentira, onde já se viu um cara pular de um avião e não morrer?!”
E o mais bizarro de tudo isso é que ele tem razão.
Nós assistimos filmes sabendo que tudo ali é ficção e mesmo assim relevamos isso sem muitos problemas, parece até que nos deixamos ser “enganados”. E não há nenhum problema disso, ou vai me falar que você não tem aquela franquia mentirosa que leva no coração?
A minha é “Velozes e Furiosos”, mesmo sabendo que todos os filmes que vieram depois do segundo, são bem ruins.
Trazendo isso pro mundo dos códigos, esse é outro mito bastante parecido com o que comentei acima sobre tamanho. Já vi pessoas atribuindo Clean Code a código mais rápido - e mais furioso. Utilizando esse argumento para afirmar que um código limpo é um código com mais performance.
Clean Code não é sinônimo de alta performance em código, mas alta performance pode ser consequência de um código limpo.
Performance de software é um assunto extremamente interessante, mas precisa de um texto único para ele, mas hoje vou me limitar apenas ao paralelo dele com qualidade de código.
Performance geralmente é atrelado a velocidade, mas será que de fato essa é a principal métrica?! Provavelmente não.
E aqui entramos em uma questão já conversada aqui. Performance é outro conceito que varia de qual área está falando sobre ele. Para um desenvolvedor ou desenvolvedora pode estar relacionado ao tempo que um algoritmo executa, para a gerência de produtos, pode ser sobre a facilidade em se implementar features novas, para o usuário final pode estar ligado a quantidade de requisições processadas durante o acesso e etc.
Portanto - falando de qualidade de código -, Clean Code é uma melhora na legibilidade do código que pode trazer performance, não o contrário.
Vamos a outro exemplo:
Primeiro código:
const arrayInteressante = [1, 2, 3, 4, 5];
for (let i = 0; i < arrayInteressante.length; i++){
// Faça algo
}
Segundo código:
const arrayInteressante = [1, 2, 3, 4, 5];
for (
let i = 0,
tamanhoDoArray = arrayInteressante.length;
i < tamanhoDoArray;
i++
) {
// Faça algo
}
Esse exemplo é ótimo para falar sobre contexto. Imagine que na sua equipe, por algum motivo, existem desenvolvedores que acabaram de migrar de área, ou de paradigma ou de linguagem e não estão tão familiarizados com certos métodos, como por exemplo o “length”.
Por mais que uma estrutura de laço possa ser familiar a desenvolvedores, o método talvez não, e por isso pode causar uma certa demora na leitura do código. No primeiro código temos um laço simples que executará algo enquanto a variável de controle for maior que o comprimento do array referenciado.
No segundo exemplo, temos o mesmo laço, porém agora foi inserida mais uma variável - tamanhoDoArray - na área de controle, apenas para deixar mais explícito que a condição se trata do tamanho da array, e isso trouxe um ganho de performance para o código, onde antes o laço precisaria checar o tamanho do array a cada iteração, agora ele acessa esse valor da variável uma única vez e itera de maneira mais rápida.
Um código maior que o primeiro, porém com mais legibilidade e por consequência, mais performance.
Esse é um bom exemplo de Clean Code.
Misery - louca obsessão (1990)
Portanto, quando ouvir ou ler sobre Clean Code lembre-se sempre de legibilidade. Quanto mais fácil para ler e entender seu código, mais limpo ele estará.
Comecei esse texto falando sobre o quanto ele serve para criar uma diferença entre bons e maus desenvolvedores, aqui reafirmo que essa não é uma necessidade importante ou muito menos algum parâmetro de avaliação pessoal, mas serve como forma de você começar a perceber sua evolução.
No final das contas, aprender uma linguagem, framework, biblioteca ou qualquer outra coisa se torna um processo mais fácil, pois é algo que você irá fazer ao longo da sua carreira, entretanto ter um código limpo está muito mais relacionado a pensar no outro - que pode ser você mesmo - do que decorar um punhado de métodos em uma documentação.
E para concluir, trate legibilidade de código, com a mesma paixão que Annie trata os textos de Paul em Misery - mas nem tanto.
Top comments (0)