Uma sugestão de como lidar melhor com código ruim
Olá!
Existem duas coisas que — para mim — definem a senioridade de uma pessoa desenvolvedora: o quanto ela é capaz de ser uma referência técnica (independente da empresa ou stack que use) e como ela lida com um código tido como ruim.
Senhoras e senhores, hoje vamos falar de código ruim!
Muito se fala (e se reclama) sobre código ruim nas comunidades de pessoas desenvolvedoras. Pode perguntar sobre esse tema para qualquer uma que você conheça, muito provavelmente você ouvirá várias reclamações ou histórias absurdas de como um código ruim arruinou vidas ou algo parecido.
Porém, se você parar para pensar sobre o assunto, a definição de código ruim é um tanto quanto vaga e há divergências sobre o que é ruim na comunidade de software como um todo. O que pode ser considerado bom em uma linguagem como objetos com estado e comportamento dentro da mesma classe em uma linguagem imperativa como C# ou Java, é considerado um sacrilégio em outras: ofereça a possibilidade de utilizar estado mutável para qualquer desenvolvedor Clojure ou Elixir e veja opiniões bem antagônicas sobre isso.
Além de definições abstratas, a forma como o texto é escrito também pode gerar divergências: em C, por exemplo, encontra-se muito código escrito com nomes de variáveis de somente uma letra, devido a um jeito de pensar dos programadores voltado a eficiência, dado os ambientes restritos em que essa linguagem costuma rodar. Já em uma linguagem OO, é recomendado por alguns livros famosos (como o Clean Code): variáveis descritivas, sem abreviações e sem se preocupar muito com o tamanho delas. Ou seja, uma variável com o nome de "valorDoProdutoPreAplicacaoDeTaxas" pode ser considerado algo bom.
O que isso significa? Simples. Não existe o certo ou verdades absolutas, apesar de existir bastante autores tentando dizer pelo menos o que é o errado (escola do qual eu faço parte, inclusive). Ninguém tem todas as respostas, mas pelo menos tentamos ajudar compartilhando experiência.
Dado que não temos uma resposta satisfatória da literatura do que pode ser considerado código ruim de uma forma absoluta (somente noções abstratas do que é code smell e recomendações de algumas pessoas que são referências na indústria de software), gostaria de propor um caminho diferente.
Vamos assumir a seguinte premissa antes de continuar: nunca julgue o código de alguém que estava escrevendo aquilo cansado às 3 da manhã para resolver um incidente ou da falta de conhecimento do analista júnior pressionado pelo suposto time-to-market de alguma pessoa de negócio que não tem a mínima noção do que é escrever software.
Pode ser também que seja um problema dado a forma como a tecnologia é vista pelo alto escalão: em algumas empresas, a área de tecnologia é um estorvo, por exemplo. Lembrando também que: o ambiente que um indivíduo está inserido faz mais pela qualidade de software do que qualquer iniciativa ou conhecimento técnico individual, mas acho que vale citar o W. Edwards Deming só para reforçar mesmo assim:
Esse cara só cunhou a frase: o que não pode ser medido não pode ser melhorado e é considerado um dos pais da melhoria contínua. Então, acho que ele sabe o que está falando.
Dado que não temos um consenso na maioria entre as tecnologias do que pode ser considerado código ruim, gostaria de propor uma ideia para que você sofra menos com o assunto, diretamente do budismo japonês (Zen). Para tal, gostaria que você olhasse para essa imagem e pensasse o que há de errado com esse bonsai da imagem:
Se você não viu nada de ruim, fica que vai ter bolo.
Se você achou a árvore imperfeita, torta ou feia, é com você que eu gostaria de falar.
O conceito de Wabi-sabi é uma forma de ver as coisas advinda da filosofia do zen budismo que em tradução para português significa algo como a beleza daquilo que é imperfeito.
Não confundir com aquela pasta verde que é ardida e você come com Sushi, isso é Wasabi.
No caso da árvore da imagem, há beleza ali, mesmo que ela esteja fora de simetria ou desgastada. É uma ideia tão flexível que recentemente está sendo usada até como conceito de design de interiores.
E o que isso tudo tem a ver com código?
Simples. Nas expectativas que nós mesmos criamos. Na maioria das vezes, esperamos que o código esteja indentado de forma simétrica ou com todas as abstrações pensadas de uma forma aderentes ao nosso jeito de pensar. Caso algo não esteja do jeito que achamos que deveria, sofremos e esbravejamos, como crianças mimadas que choram ao receber um não.
O código de um software também sofre de entropia, o que o tornará feio, imperfeito e (supresa!) legado ao longo do tempo. Não importa a quantidade de testes unitários. E está tudo bem. As coisas são assim mesmo, elas envelhecem, apodrecem e morrem. Cabe a nós aceitar a impermanência de todas as coisas para viver melhor e deixar de sofrer com coisas pequenas. Para tal, gostaria de citar o conceito de Anicca (que é uma outra palavra para designar impermanência):
Basicamente, todos os fenômenos são impermanentes. Entenda-se por fenômeno qualquer ideia de existência, seja de um “eu”, de um “outro”, de um “objeto”, de uma “experiência” etc. Os fenômenos são impermanentes devido à sua natureza composta, ou seja, existem a partir de causas e condições. Quando as causas e condições cessam, o fenômeno cessa também.
Os relacionamentos cessam, os governos, os países, as empresas… todos cessam, mudam o tempo todo, pois dependem de outros fatores, que, por sua vez, também são compostos e assim sucessivamente.
Podemos perceber a impermanência operando em nossas vidas diariamente. Contemplar isso é de extrema utilidade, pois faz cessar o nosso apego exagerado, o nosso “agarrar” exagerado.
E porque eu disse tudo isso? Será que esse texto é um ode ao código lixo ou até mesmo um manifesto em defesa do Extreme Go Horse Process?
Nada disso. Ainda vale estudar conceitos fundamentais, como estrutura de dados e algoritmos. Big-O-Notation. Conceitos de sistemas distribuídos. Filas. Gerenciamento de memória. Actor model. Conceitos de extrema tolerância a falhas, como Erlang/OTP. Compiladores. E o que mais você achar que deve para se tornar uma pessoa desenvolvedora melhor.
Porém, ao invés de esbravejar contra o "legado" ou contra o "maldito programador que fez uma complexidade ciclomática de 15 nesse método", pense: vale a pena gastar energia reclamando ao invés de resolver o problema? Se isso não funcionar para você perceber que não vale o desgaste, memento mori resolve.
Dedique-se a arte de escrever código, também há beleza na ritualística da profissão de pessoa artesã de software (curiosidade: esse cuidado com detalhes e senso de excelência também é encontrados na ritualística budista), porém, não se desgaste no processo. Tem que ser divertido lidar com código, senão para que fazer?
Até!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
