Executando verificação de segurança...
3
fabioscript
7 min de leitura ·

Clean Code no Cinema

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.

Fonte: https://dev.to/fabiodeandrade/clean-code-no-cinema-3eke

Carregando publicação patrocinada...
2
maniero

Estava prestes a positivar a postagem quando vi o segundo exemplo.

Em parte tem o gosto. Eu acho a segunda forma bem menos legível que a primeira, principalmente porque eu, e quase todo mundo, estamos acostumados com a primeira.

Contexto é importante. E estar acostumado é um contexto importante. Em muitos casos, até fazer "menos certo" pode ser melhor pelo contexto.

Ainda bem que não mudou i por contador. Muita gente defende isso e diz exatamente o que está está escrito aí, é mais legível usar um nome de variável que diz o'que ela é. Mas a pessoa ignora que i diz melhor ainda, porque as pessoas estão acostumadas. E a pessoa diz que precisa fazer isso porque assim é "Clean Code". Ou seja, a pessoa leu o livro, não entendeu nada e fez errado. O livro pode ser uma faca de dois gumes, porque se a pessoa não souber aplicar, ela começa implementar o que aprendeu de forma equivocada. A pessoa usou o livro como receita de bolo, que eu sempre falo que não pode ser feito.

Por isso eu recomendo ler o livro porque ele ensina muita coisa, mas com criticidade, porque ele ensina errado algumas coisas, e porque a pessoa vai ignorar a parte do contexto ela aprenderá errado, mesmo que o livro ensinou certo.

E se i é mais adequado que contador, então por que tamanhoDoArray é mais adequado que arrayInteressante.length? Simples, não é.

As pessoas estão acostumadas com a forma direta sem variável, então é mais legível assim. As pessoas sabem que isso é o tamanho do array, e quem não souber não sabe programar ainda, tem que passar longe do Clean Code, não é hora pra isso. È como fazer isto (caso real em um lugar que eu trabalhei, e que pedi demissão porque quem mandava dizia que tinha que fazer assim porque estava no Clean Code, e eu não trabalho com gente estúpida):

    //este método inicializa os componentes
InicializaComponentes();
A justificativa era que o estagiário precisava entender. Isso está errado por várias razões, e lamento se não as percebe.

Mas tem mais problemas. Semanticamente os dois códigos são diferentes. Pode ser que não faça diferença, e é comum não fazer, até que faça. Até que alguém mude algo lá e faça. Pode ser que a segunda forma seja a mais correta, mas precisa analisar o contexto. Pode ser que não queira garantir que o tamanho seja fixo, pode ser que o tamanho mude dentro do laço, ou concorrentemente.

E tem a questão da performance. Dependendo da tecnologia usada (não necessariamente a linguagem) pode ser que o segundo caso seja menor performática, ou pelo menos seja igual. Especular sobre o que parece intuitivo nunca é bom sobre performance. Existem casos reais que não ocorrem de fato. Muitas linguagens otimizam isso e não precisam ter essa preocupação.

Também é questão de gosto e costume, mas escrever o for separando em linhas é bem esquisito, me parece menos legível, e talvez nem seja o caso de usar um for. Indentação dupla no mesmo bloco como se fossem dois blocos torna menos legível, pelo menos para quem está treinado de outra forma, mas provavelmente em qualquer caso.

Sem falar que provavelmente deveria usar um for ... of (se não for JS pode ser um for each ou algo parecido).

E minha discordância final é que ser legível e ter mais performance não andam juntos. Tem casos que até é verdade, mas frequentemente não ocorre, o legível deixa menos eficiente. O que pode não ser problema, mas ocorre. Existem muitas exceções, mas códigos maiores tendem ser mais lentos, sem entrar em casos específicos.

Claro que a base do texto está correta. O perigo mora nos detalhes. Porque assim evita ser uma psicopata com seu ídolo embaixo do braço. Se você fizer algo que as pessoas naõ estão acostumadas, você está pensando em você, não no outro.

Por isso que eu semrpe falo que é preciso aprender todos os fundamentos, os conceitos, as nomenclaturas e os padrões que todos conhecem. Imagine uma junta médica conversando com "dodói disso, dodói daquilo", as pessoas precisam falar a mesma língua que seja inequívoca entre profissionais.

Em engenharia temos que dominar todos os aspectos, caso contrário... (veja o vídeo).

Faz sentido para você?

Espero ter ajudado.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

1
fabioscript
Autor
Autor

Extremante importante teus apontamentos, Maniero!

Muito obrigado pela contribuição, o que você comentou reafirma algo que concordo bastante, os detalhes.

As vezes sinto que pessoas comentam sobre Clean Code se referenciando algo que "eu fiz ou não fiz hoje", algo binario, quando na verdade é uma construção ao longo do tempo - com ou sem um time.

O contexto, na minha opinião, é a chave pra esse entendimento em conjunto. Como por exemplo o própio portugues brasileiro com seus sotaques e girias, onde certas expressões estão alocadas apenas naquela determinada região e aplicadas em outros lugares pode trazer bastante confusão.

Uma vez estipulado e entendido por todos, a saúde e qualidade do código ganham aumento expressivos, principalmente na economia de tempo e dinheiro.

1
1
1
1
1
1
balavalda

Acho Clean Code over hyped, sinceramente, muita gente faz código mais ilegivel do que um código procedural usando premissas do Clean Code. Clean Code varia de contexto e empresa e é algo que precisa ter cuidado ao se fazer.