Atenção: esse artigo tem um vídeo complementar. Clique e assista!

Que atire a primeira pedra quem nunca disse ou ouviu a frase: “Acho que vai ser mais rápido reescrever do início do que alterar o que temos hoje.”. Isso é mais comum do que muitos imaginam. Se fosse possível montar um gráfico de produtividade x tempo em um novo projeto, é muito provável que a produtividade nas primeiras semanas seria altíssima e com o passar do tempo iria diminuindo, cada versão colocada em produção faria esta medida diminuir ainda mais. A linha de produtividade tenderia a zero. Isso significa que sempre seria possível adicionar novas funcionalidades, mas a velocidade seria cada vez menor. Quanto mais perto do zero, mais essa frase tão temida aparece. Claro, estou generalizando, nem todos os projetos são assim, mas, infelizmente, a reescrita ou a “podridão” do código é o futuro de um bom número de projetos.

São vários os motivos que levam um software a chegar a tal estado, muitas vezes é a má comunicação entre a equipe, má qualidade da escrita do código, falta de motivação, pessoal não qualificado, maior foco em processos e ferramentas ao invés de um software funcionando, complexidade técnica, excesso de dívidas técnicas entre outros.

O ponto que este artigo está focando é sobre qualidade de código e como garantir que o software tenha um código saudável para que seja possível adicionar valor de forma menos árdua. Grande parte das dicas e orientações desse artigo podem ser encontadas no excelente livro de Robert C. Martin (também conhecido como Uncle Bob) chamado: “Clean Code: A Handbook of Agile Software Craftsmanship”. Na seção Links é possível encontrar uma URL que aponta para o blog do Uncle Bob que trata do livro mencionado. A leitura é obrigatória para desenvolvedores que desejam melhorar suas habilidades através da escrita de código limpo.

Código Limpo

Conforme o software vai crescendo, novas linhas de código são acrescentadas ou alteradas a fim de atender algum requisito novo ou então corrigir algum bug encontrado. Essas alterações fazem com que o código existente comece a ficar menos legível do que estava antes. A tendência é que o código fique cada vez mais podre e comece a surgir alguns “maus cheiros” (ver nota do DevMan). Isso acontece, pois ninguém escreve o código ideal da primeira vez, até porque muitas vezes nem se sabe qual seria o ideal.

Sempre que está sendo feito uma alteração na base de código e o objetivo da alteração envolve alguma necessidade de negócio, é comum que as preocupações com nomenclatura e clareza do código fiquem para trás já que o foco naquele momento é adicionar algum valor de negócio. Isto é perfeitamente normal e aceitável, nesta fase não há porque se preocupar tanto em escrever o código mais bem desenhado possível. Este tipo de melhoria deve ser feita em uma etapa separada, refatorar e adicionar uma funcionalidade ao mesmo tempo pode ser mais demorado e difícil, além de ser provável que nenhum dos dois seja feito corretamente.

Um ponto que pode ser questionado aqui é, por que alterar se está funcionando? Uma citação muito conhecida do Martin Fowler diz: “Qualquer tolo consegue escrever código que um computador entenda. Bons programadores escrevem código que humanos possam entender”. É fácil escrever um código que compila, o difícil é fazê-lo expressivo o suficiente para que os outros membros do time consigam compreender também. O ideal é que o código fale a língua do leitor sem que ele tenha que forçar a mente para entender. Se for fácil entender, será fácil alterar.

Nota do DevMan

Mau Cheiro - Um mau cheio (do inglês, bad smell), em desenvolvimento de software, é definido como sendo um pedaço de código mal escrito ou mal desenhado, algo que causa um certo desconforto ao ser lido. Mau cheiro não é o que é conhecido popularmente como “gambiarra”. Normalmente uma gambiarra causa um mau cheiro, mas o contrário não é verdade. Alguns exemplos de mau cheiro podem ser: uma classe com 500 linhas, um método com 100 linhas, um método com 10 parâmetros, uma classe com 30 métodos estáticos onde cada um faz algo em um contexto totalmente diferente, entre outros. "