Recentemente iniciei a leitura do livro “Clean Code” de Robert C. (Uncle Bob) Martin. É um livro que descreve boas, eu diria ótimas, práticas de desenvolvimento relacionadas exclusivamente ao código fonte de aplicações. As observações do livro também não apontam para uma linguagem específicas, portanto podem e devem ser aplicadas com todas as linguagens.

Logo no começo do livro, capitulo 1 ou 2, ele menciona que: “Programar, codificar uma aplicação é uma atividade social“. Não se trata de uma tradução literal mas essa é a mensagem. Achei a afirmação muito interessante, e confesso que jamais havia pensado na tarefa de codificação como uma prática social. Eu sempre enxergava, tomando como exemplo um projeto open source qualquer, o ato de criação do projeto e mesmo o trabalho em equipe nesse sentido mas nunca o código em si. Normalmente pensamos da seguinte maneira: “O código é meu!“. Eu diria que essa afirmação é verdadeira até que você faça o commit do “seu” código para o repositório, depois disso, não mais.

Não está entendendo? Explico já. O Uncle Bob coloca em seu livro que devemos ter muito cuidado com o código fonte que escrevemos, porque afinal de contas quando o fazemos, estamos quase sempre fazendo isso para que outras pessoas “leiam” o nosso trabalho. O ato de escrever em si traz consigo esse sentido, ou seja, geralmente escrevemos algo para um outro alguém ler. Em nossa profissão isso também não é diferente, pois nada garante que o autor original do código será a pessoa que dará manutenção no mesmo.

Como o Uncle Bob tanto insiste no livro, o código que escrevemos precisa ser muito claro e direto, ele precisa ser capaz de transmitir sua intenção de forma objetiva, para que as outras pessoas que forem ler o código não percam um enorme tempo tentando entender o que pretendíamos com aquilo. Quantas vezes você já se viu nessa mesma situação? Quanto tempo já não perdeu por conta disso? Não seria ótimo encontrar um código que falasse com você, quando precisar dar manutenção nele? Reflita sobre isso. Tente imaginar como será dar manutenção no código que você acabou de escrever. Será que você mesmo vai conseguir entender ele depois de uns 2 ou 3 meses? Experimente chamar um colega e pedir para que ele “leia” o “seu” código para ver se a intenção está clara para ele. Só não vale dar pistas :-) Se ele não entender, pare, reescreva e depois chame uma pessoa diferente e peça que leia. Faça isso até que as pessoas não tenham nenhuma dificuldade para interpretar o seu código.

Se você é desenvolvedor e estava procurando uma boa leitura, eu recomendo fortemente esse livro. Aliás, eu penso que o sujeito não devia sair da faculdade sem antes tê-lo lido. É o tipo de livro que todo profissional da área de computação e sistemas deve ler e as empresas deviam ter em suas bibliotecas.