DEV Community

Cover image for Clean code, de Avril Lavigne a batatas
Fábio de Andrade
Fábio de Andrade

Posted on

Clean code, de Avril Lavigne a batatas

Oi, me chamo Fábio e assim como você sou uma pessoa que desenvolve softwares.

O que?! Você não desenvolve?!

Claro que sim, não é porque talvez você ainda não esteja recebendo por isso que não seja, mas se você veio atrás desse assunto é porque você, sim! já é uma pessoa desenvolvedora.

Pode achar que estou escrevendo isso de forma genérica, pra um monte de gente, mas queria te certificar de uma coisa, eu estou escrevendo esse texto para duas pessoas:

Para mim e para você.

Eu lembro perfeitamente no dia que ouvi alguém falando sobre “Clean Code”. Não fazia ideia do que era, pesquisei e pesquisei até encontrar certos materiais que mais me confundiam do que me ajudavam, mas de uma coisa eu tinha certeza, esse assunto seria - e é - extremamente importante pra mim.

E por isso queria fazer um contrato com você agora. Até o final do texto eu vou te ensinar algumas coisas e você vai ser capaz de:

  • Entender o que é Clean Code
  • Saber um pouco da história - sim, é importante também.
  • Saber quando e porque usar.
  • Como isso vai mudar sua carreira para sempre.
  • Fazer arte.
  • Limpar seu quarto.

Em troca eu só peço uma coisa:

Que você chegue ao final desse texto e responda a pergunta do último parágrafo.

Estamos entendidos?


Eu sei o que você veio fazer aqui

Como disse acima, eu sei que você veio parar aqui pelo mesmo propósito que eu tive em procurar sobre o assunto, e a boa notícia, é que você não apenas programa, mas sim desenvolve.

Você se importa com a qualidade do que você entrega, e aqui queria parar um pouco sua leitura para te fazer uma pergunta safada:

*Você sabe o que entrega além do código? *

Não precisa responder agora porque vamos descobrir ao decorrer do texto.

Existe uma diferença muito grande entre quem programa e quem desenvolve. Um programador ou programadora na maioria das vezes é apenas o ser vivo entre a cadeira e o computador que digita o código para o computador executar da forma que lhe foi solicitado.

E só…

Pra mim isso é um saco. Receber instruções de outras pessoas para colocar instruções em computadores. Quem é a máquina no final desse ciclo?

Do outro lado da rua está a pessoa que desenvolve.

Ela não apenas passa as instruções para o computador, mas como também pensa sobre o que está fazendo, para quem está fazendo e, além disso, como está fazendo.

Para ser um programador ou programadora você só precisa de um computador.

Para ser um desenvolvedor ou desenvolvedora, você precisa ter coração - e um código limpo.


Cheira tão mal assim?

Imagine a cena.

Você abre sua IDE, baixa o código no qual vai trabalhar, depois de alguns minutos lendo aquele código, algo começa a embrulhar no seu estômago, coceiras aparecem pelo corpo e você começa a perceber que um meteoro não seria tão ruim para a humanidade.

Esse é um dos efeitos colaterais em se trabalhar com um código ruim. Raiva, angústia, vontade de quebrar algo e proferir uma quantidade enorme de palavrões por minuto, e é bom você saber dessa métrica a seguir.

“Um código bom - ou limpo - é inversamente proporcional à quantidade de palavrões por minuto que uma pessoa solta ao ler tal código.”

Provavelmente você já ouviu a expressão “Isso está cheirando mal!”. É exatamente o que você deveria falar quando começa a ler um código ruim e talvez - opinião minha - o termo “code smells” tenha alguma origem nessa expressão.

Portanto, a partir de agora, sempre que você ouvir ou ler essa expressão, saiba que estão se referindo a código ruim.

E essa é uma das habilidades que você precisa desenvolver a partir de hoje. Não só ler ou escrever códigos, mas sim sentir o cheiro deles para - agora sim - conseguir limpá-los da melhor maneira.

Então estamos claros? O clean code é uma forma de - literalmente - limpar um código para que ele seja mais “cheiroso” para os outros desenvolvedores, ou você do futuro.

Guarde essa informação, pois vamos falar um pouco mais dela à frente.

Ok, Fábio, mas de onde surgiu isso?

Sem muitos rodeios, o principal símbolo do Clean Code é um livro lançado em 2008 que leva esse nome, e nele você conhece uma relação de boas práticas na hora de criar códigos e - o principal - o motivo para fazê-lo.

Antes de continuar o texto queria roubar um pouquinho da sua atenção para esse ponto. Se você não pretende comprar livros de tecnologia, sugiro fortemente rever esse pensamento.

Livros de tecnologia são ótimos! Entretanto sofrem de um problema que eu e você sofremos, eles envelhecem.

Assim como nós, a tecnologia é viva. O que você aprendeu hoje, provavelmente já terá uma versão atualizada amanhã, e no final das contas o que sobra para absorvermos é a experiência e o repertório que elas nos dão.

Alguns livros envelhecem muito mal, ao ponto de estarem defasados em questão de meses e outros parecem ter genes da Avril Lavigne.

O Clean Code parece estar no meio dessa escala Lavignesca. Ele foi criado em um determinado momento da história sob circunstância quase exclusivas daquele cenário e tempo, mas como disse acima, você deve absorver, não só as dicas, mas a experiência e forma de pensar na hora de resolver problemas - isso nunca envelhece.

De maneira bem resumida, o livro foi “escrito” por Robert Cecil Martin, ou Uncle Bob (“tio bob") como geralmente é chamado. A palavra escrito não está entre aspas de à toa, apesar de levar a autoria da obra, Martin teve ajuda de outras grandes pessoas do mundo da tecnologia para nos trazer essa belezura de livro.

Apesar de algumas polêmicas, Martin é importante para alguns pontos que vamos conversar hoje. Além de ser autor de ótimos livros de tecnologia como o Clean Architecture, Clean Agile, Clean Coder e o próprio Clean Code; o tio Bob levantava algo que eu defendo muito sobre escrever código.

Somos artistas!

Mas vamos falar disso mais tarde.

O Clean Code é fácil de ser encontrado na internet, com preços bem acessíveis, desde mídias físicas a digitais. Aqui afirmo que ele é uma leitura obrigatória, mas não é uma leitura urgente e nem aquela que você precisa ler da noite para o dia.

Da primeira vez que eu li, se entendi 40% foi muito, depois da segunda leitura consegui entender um pouco mais, e a cada nova leitura me surpreendo com algo novo. Então se posso sugerir uma forma de ler ele, leia no tempo do seu conhecimento.


Clean Code e batatas

O livro foi escrito para trazer técnicas, um quanto filosóficas, sobre como deixar um código mais limpo, assim como também, utilizar tais técnicas para economia de dinheiro, tempo e uma melhor saúde mental.

Ele traz uma relação de grandes problemas que Martin descreve ter tido ao longo de seus anos atuando como desenvolvedor. Em algumas entrevistas ele comenta que já trabalha com códigos desde os anos 70, limpando, escrevendo, debugando e - principalmente - lendo código dos outros.

E aqui quero já deixar uma coisa clara, se você gosta de Javascript assim como eu, saiba que no livro a maioria dos exemplos são em Java, mas nada que atrapalhe a sua compreensão.

Esse talvez seja o ponto que mais divide a opinião dos leitores. Martin escreve sobre um contexto vivido por ele há alguns anos, onde tecnologias eram diferentes, editores de códigos eram diferentes e até mesmo a linguagem que ele usava, é diferente da que se usa hoje.

Por exemplo, no livro ele comenta sobre alguns problemas de indentação, de como isso prejudicava a leitura e por não ter um padrão, os desenvolvedores faziam da maneira que lhes dava na cabeça.

E hoje apertando duas teclas, em qualquer editor de código, esse problema se resolve em um segundo.

Isso pode parecer um tanto quanto inútil nos dias de hoje, mas a lição que você deve tirar disso não é sobre a facilidade ou a maravilha de se viver com tecnologias que resolvam isso de maneira simples, mas sim:

  • Como isso era um problema
  • O que impactava para os desenvolvedores
  • Qual o pensamento por trás da resolução

Eu tenho certeza que se você olhar por essa ótica, conseguirá encontrar problemas parecidos e usar soluções quase idênticas.

Fábio, e as batatas?

Coincidência ou não, o Código Limpo foi publicamente lançado em 2008, no mesmo ano para o qual foi eleito - pela ONU - o ano internacional da batata.

Não acredita em mim? Então vai rapidinho no Google e depois volta pra cá.

E aproveitando o papo, você sabia que limpeza e batata tem tudo em comum?

Batatas possuem ácido oxálico, sendo um componente químico letal em grandes doses, porém em pequenas é excelente para fabricação de tintas, corantes e melhor ainda para eliminar gordura e ferrugem.

Talvez seja esse o motivo para a ONU escolher o ano da batata o mesmo ano do lançamento do Clean Code?!


Clean Code e carreira

Eu já enchi o saco de muita gente nessa vida, não ao ponto de ser insuportável, mas sim em perguntar a mesma coisa para pessoas diferentes.

No últimos anos, uma das perguntas que sempre gostei de ouvir respostas diferentes foi:

Como um ou uma jr pode virar pleno ou plena?

Tive respostas curtas, longas, diretas, enigmáticas e até bem filosóficas, mas houve um tema específico que se repetia em 99% delas.

Código Limpo.

Ter um código limpo não é um mero capricho, ou algo para mostrar a seus superiores como você consegue resolver uma cadeia imensa de ifs utilizando switch.

Vai muito além disso, podendo passar por temas como qualidade de código, economia, base forte de programação entre outros, mas o aspecto crucial de escrever um código limpo é a empatia.

Queria que você guardasse no coração essa palavra.

Escrever um código limpo é se importar com quem vai lê-lo.

Não ache que o computador vai se importar com o seu código, isso é bobagem. Os computadores querem saber se funciona ou não. Você pode gastar 900 linhas para rodar um simples for, eles não vão ligar para o jeito que você escreveu.

Apesar de serem uma parte do nosso público, queria que a partir de agora você prometesse para mim e para você que escreverá códigos primeiramente para outras pessoas e depois para computadores.

E você se inclui nesse grupo de pessoas também.

Ou está achando que nunca mais vai tocar naquele código que escreveu meses ou anos atrás?!

Essa é uma das melhores habilidades de uma pessoa que desenvolve software, a percepção e a preocupação de quem vai pegar seu código depois de você.

Não veja - ou veja - como romantismo tecnológico, mas eu sei que um dia você vai me agradecer por levar isso a sério.

Não só por saber que está ajudando outra pessoa, mas por ter reconhecimento disso em sua carreira.

Vão cobrar de um jr que ele apenas faça o código rodar.

Vão cobrar de um pleno que ele faça rodar e que esteja limpo.

Você quer ser jr por quanto tempo?!


O Show vai começar

Ontem a noite eu vi o filme do Elvis, apesar de não ter escutado muito suas músicas, o que a história despertou em mim foi surreal.

Imagine o Elvis, que se dedicou aos montes para fazer algo que gostava. Noites em claro treinando, treinando e treinando. Aperfeiçoando cada vez o sua habilidade, e no final, recebia dinheiro e aplausos de todos.

Um grande artista!

Quantas desenvolvedoras e desenvolvedoras não tem histórias parecidas com a do Elvis?! Não no sentido literal de sua história de vida, mas falo sobre a dedicação em se fazer aquilo que se propõe e gosta.

Tenho amigos e amigas que dedicam horas de estudo e prática todos os dias em desenvolvimento de software, trazendo paixão em cada linha de código e se importando em dar uma experiência agradável para quem vai usufruir dessa habilidade.

O que os diferencia de artistas?!

Nada!

Ambos dedicam sua vida e habilidades para entregar uma boa experiência a alguém. A maior diferença é que na programação a arte é compartilhada, criada sob muitas mãos e o melhor de tudo, traz uma experiência não só para o público final, mas para nós mesmos quanto artistas.

Parece muito romântico mais uma vez, não é?!

Mas me permita fugir um pouco do assunto para te mostrar algo bem legal.

Quando um artista faz algo que todos conseguem perceber que de fato aquilo é arte? Que aquilo foi muito bem feito?

Todos vão à loucura, suspiram, gritam, batem palma, assobiam ou demonstram sua satisfação de alguma forma.

Em 2018 Dan Abramov, um desenvolvedor assim como eu e você, palestrou durante alguns minutos na React Conf. Durante a palestra ele fez uma demonstração de um código, que não só trazia melhorias para a ferramenta, mas sim a deixava mais limpa.

Dá pra ver claramente seu nervosismo durante a apresentação, mas quando tudo dá certo sabe o que acontece?

Não vou estragar sua experiência, clique no link aqui embaixo e pule para o minuto 22:25.

Dan é um artista, assim como eu e você.

E sabe o que ele mostrou nesse vídeo?

Limpeza de código.


Meia no chão e toalha na cama

Eu sei que nesse ponto eu posso ter decepcionado você. Deve estar se perguntando “onde está o código que vai mudar minha carreira?”, ou como acabar com aquele aninhamento de ifs ou o famoso callback hell.

E aqui quero fazer um mea culpa; de fato não vou te mostrar isso hoje, mas vou te ensinar algo melhor.

A arrumar seu quarto!

O primeiro ponto é:

Preste atenção nas coisas que entram no seu quarto.
Nós dois sabemos que se algo entra no quarto, seja uma sacola, chiclete, garrafa ou copo, isso só vai sair depois de uns bons dias e provavelmente haverá coisas que ficarão para sempre.

Então para evitar isso, comece a perceber as coisas que você leva para dentro do quarto.

Se você pode fazer algo em outro lugar, como beber um copo de água na cozinha, ou deixar os sapatos na entrada da casa, o faça.

Deixe lá, não precisa trazer para dentro do quarto, ou crie algo que impeça que essas coisas entrem no quarto.

Arrume uma coisa de cada vez
Não comece retirando os papéis do chão no mesmo momento em que dobra seu lençol ou tira a toalha de cima da cadeira.

Se proponha a limpar algo, faça, termine e vá limpar outra coisa.

Isso faz com que você não se perca na hora de concluir algo, ou muito menos na responsabilidade que você tem naquele momento.

Por mais que seja simples, se você precisa apenas tirar a meia do chão, comece e termine essa única tarefa antes de ir para outra.

Cuidado com o que você tira no final da limpeza
Não saber organizar a limpeza do seu quarto pode trazer dores de cabeça bem chatas.

Imagine que durante a limpeza, você trouxe a vassoura para o quarto, deixou ali no canto, pegou um bolo de roupa suja que estava na cama e levou para máquina de lavar. Depois de uns bons dias percebeu que no meio das roupas havia um pedaço de papel importante.

Ou para piorar, você talvez nem se lembre ou saiba que algo de valor foi junto com as roupas.

Já perdi uns bons reais assim dentro de calças e bermudas.

Portanto, preste bastante atenção com o que você leva para fora do quarto, pois nunca se sabe se algo de valor - ou constrangedor - foi para fora.

Para finalizar vamos relembrar:

  • Preste atenção em tudo que entra no seu quarto.
  • Arrume uma coisa de cada vez.
  • Cuidado com o que você tira do seu quarto.

Agora que você já sabe arrumar seu quarto, vamos arrumar seu código?!

Imagine que seu quarto é uma função que precisa somar 2 números.

 function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 // aqui é o seu quarto
 }

Enter fullscreen mode Exit fullscreen mode

O primeiro passo é se preocupar com o que entra na nossa função, assim como as coisas que entram no seu quarto.

Se eu preciso somar dois números, não existe motivo para eu deixar outros tipos de dados entrarem na função, por isso o melhor a se fazer é prevenir que isso aconteça.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;
 // aqui é o seu quarto
}
Enter fullscreen mode Exit fullscreen mode

Se os tipos de dados que chegarem a função forem diferentes de número, o fluxo acaba ali mesmo.

Agora devemos fazer uma única coisa de cada vez, ter apenas uma responsabilidade por tarefa.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;

 const resultadoDaSoma = primeiroNumero + segundoNumero
 // aqui é o seu quarto
}
Enter fullscreen mode Exit fullscreen mode

A função apenas soma e nada mais.

E por último, tenhamos certeza do que está saindo da nossa função - ou do nosso quarto depois da limpeza.

function SomarDoisNumeros(primeiroNumero, segundoNumero) {
 if(typeof primeiroNumero !== "number" && typeof segundoNumero !== "number" return;

 const resultadoDaSoma = primeiroNumero + segundoNumero

 return resultadoDaSoma;
}
Enter fullscreen mode Exit fullscreen mode

Assim como seu quarto, esse código agora está limpo e o mais importante, ele está totalmente legível para outras pessoas.


Você está me devendo!

Lembra que lá no início nós fizemos um acordo?!

Eu iria te ensinar umas coisas e você me responderia uma pergunta.

Então, depois de conversamos sobre a necessidade de limpar um código, sobre como você - SIM - produz arte, sobre carreira, limpeza de quarto e sobre a importância de se preocupar genuinamente com a outra pessoa que irá pegar seu código:

Você quer ser uma pessoa que só programa ou que desenvolve?

Até a próxima 👋

Top comments (3)

Collapse
 
iagocavalcante profile image
Iago Angelim Costa Cavalcante

Bem legal a forma que você abordou o tema, eu acredito que apesar do clean code, eventualmente alguns devs chegam ao mesmo ideal só trabalhando e sem ler o livro. Hoje gosto de pensar numa abordagem que acaba levando a um código mais limpo, essa abordagem está relacionado à capacidade cognitiva das pessoas, e ao contrário do livro que é repleto de opiniões pessoais do autor, Programmers Brain, esse livro aborda de forma científica como atingir algumas coisas que facilitariam a vida útil de uma code base.

E ai me leva a apresentar pra você uma metodologia que vem sendo criada por brasileiros e tem sido levada para o mundo acadêmico. O CDD (Cognitive Driven-Development) .

Collapse
 
fabiodeandrade profile image
Fábio de Andrade

Essa abordagem é boa demais! Já tinha ouvido falar sobre, mas depois desse vídeo me deu mais curiosidade de me aprofundar, obrigado por compartilhar!

Collapse
 
iagocavalcante profile image
Iago Angelim Costa Cavalcante

É nós meu conterrâneo!