É muito comum que iniciantes na programação, no começo de seus estudos, tenham tendência a escrever códigos complexos, aplicando nomenclaturas da maneira mais hacker possível e se esforçando para deixar seu código mais longo, por associar tal complexidade a um maior entendimento do conteúdo; admirando seu código complexo, suas variáveis de nomes complicados e suas enormes funções, o(a) garoto(a) se sente o próprio Elliot Alderson:

Todos nós, ou quase, passamos por esta fase. Contudo, com o passar do tempo, percebemos que estavámos sendo demasiado juvenis. Gostamos de código limpo, legível, modular, curto e simples. Facilmente nos irritamos com nosso colega que escreve AQUELA função gigante, AQUELA variável de nome 'x' (mas sempre somos educados ao corrigi-lo, ok, amigos?).

Mas acontece que qualidade de código passou a ser indispensável no mercado de trabalho, pois esse fator ganhou bastante atenção nas últimas décadas. Mas por quê?

Vou lhes contar uma historinha:

Nos anos 80, uma empresa desenvolveu uma aplicação sensacional. Algum tempo após se tornar bastante popular, a aplicação começou a declinar. Os ciclos de releases (entregas) começaram a se alongar e problemas como bugs e grande tempo de carregamento começaram a se acentuar na aplicação. A empresa saiu do mercado pouco tempo depois. Muitos anos depois, um ex-funcionário revelou o ocorrido: na pressa para jogar a aplicação no mercado, os desenvolvedores fizeram uma verdadeira bagunça no código. Na medida que a aplicação crescia, a bagunça só aumentava, até que a manutenibilidade do código foi pro espaço! O código ruim foi o culpado pela queda da empresa!

Contudo, apesar de não gostarmos de código sujo, será que temos em nossa mente as diretrizes do clean code? Podemos até não escrever código desnecessário à toa ou não nomear nossas variáveis com 'x', 'y' ou 'z', mas será que estamos nos empenhando em deixar nosso código legível? simples? de fácil entendimento? 

Não é verdade que por vezes escrevemos funções longas sem perceber? Que, ao tentar das manutenção no nosso código de uma semana atrás, temos dificuldade para entendê-lo, percebendo assim que não estava tão legível assim? Que, quando mentalmente exaustos ou sob pressão do gerente, deixamos aquela bagunça para outro dia?

Engraçado, recentemente vi uma frase da qual não lembro a autoria, mas que dizia:

"O outro dia nunca chega."

E a produtividade?

Como de se imaginar, o grande problema é sobre a manutenibilidade do código. Programadores experientes com certeza já foram atrasados pelo código de alguém durante a sua vida. Cada alteração quebra o sistema em outros pontos, pedindo mais mudanças, de forma que times que se moviam muito rapidamente no começo passaram a se mover demasiadamente lentos. Em um sistema assim, o time tem de entender os emaranhados e nós em diversos pontos, a fim de criar mais emaranhados e nós. A partir deste ponto, NENHUMA mudança é trivial. E o que acontece é o esperado:

A produtividade do time tende a ZERO. 

Torna-se, então, perceptível o grande custo de possuir essa bagunça. Agora nos é óbvio que esse tempinho a mais que tiramos para refatorar nosso código antes que ele se torne uma bagunça, é um investimento baixo que tende a trazer um enorme retorno.

"Mas como eu convenço meu gerente? Se eu não fizer o que ele quer, vou ser demitido."

Não, provavelmente você não vai ser demitido. Os gerentes querem a verdade, ainda que não pareça. Ele quer bom código, ainda que pareça mais preocupado com os prazos, mas veja bem: esse é o papel dele. O seu papel, enquanto desenvolvedor, é expressar as dificuldades e as necessidades da equipe técnica. A perfeição é alcançada quando os dois lados se entendem perfeitamente.

Nessa situação, a comunicação é importantíssima, e se você "deixar por isso mesmo", obedecendo cegamente os prazos estabelecidos, ainda que isso resulte em código ruim, um dia o projeto irá ruir; adivinha de quem é culpa?

E o que eu faço?

"Ah, mas como eu implemento isso na prática?"

Não é tão difícil como parece. Desenvolvedores com décadas de experiência em desenvolvimento geralmente dão ênfase à teoria das Janelas Quebradas e como esta impressionantemente se prova verdadeira, constantemente. Não conhece? A história é a seguinte: psicólogos americanos, conduzindo uma experiência, abandonaram um carro em bom estado, em um bairro nobre. Muito tempo passou e o carro continuou intacto. Em determinado dia, a equipe quebrou as janelas do carro e novamente o abandonaram. O que aconteceu era esperado: o carro rapidamente se tornou alvo de furto e destruição. Lição de moral:

Desordem gera desordem!

Comece evitando a desordem. Cada pequena atitude é extremamente importante para impedir a bagunça de adentrar seu código. Dê uma olhadinha na regra do bom escoteiro.

E agora?

Sobre as diretrizes, são muitas. Se quiser se sentir mais confortável e seguro no assunto, sugiro o livro  Clean Code, de Robert C. Martin (mais conhecido como Uncle Bob). Contudo, existem diversos artigos pela web que vão direto ao ponto, mas você nem precisa sair do blog da TriadWorks!

Este artigo lhe dará uma breve introdução sobre o assunto, e se quiser aprender mais sobre o assunto, visualize todos os artigos relacionados através da tag Clean code!

Obrigado por ler e mantenha seu código limpo!