Data Binding - Artigo .net Magazine 85

Refatoração

Refatoração é o nome dado à técnica onde são feitas pequenas alterações a fim de melhorar a legibilidade do código, aumentar o desempenho, melhorar a estrutura do projeto ou remover duplicações sem que isso afete o comportamento externo do software. Dentre os diversos problemas que levam à necessidade de refatorar, os que serão abordados neste artigo são: nomenclatura pouco expressiva, método muito extenso, uso indevido de comentários, método com muitos parâmetros, código duplicado ou inutilizado.

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.

A refatoração e suas analogias

A analogia entre o código fonte e a cozinha é bastante interessante e pertinente. O que aconteceria se a louça do almoço fosse deixada suja sobre a pia? Muito provável que a janta iria demorar um pouco mais para ficar pronta. Se esta por sua vez também for deixada suja, o almoço do dia seguinte será prejudicado, pois, poderão faltar pratos, copos ou panelas. Por isso, torna-se um hábito comum limpar a cozinha após cada refeição. Com um software não é diferente, à medida que se vai adicionando mais e mais linhas de código, o software como um todo começa a ficar internamente sujo. A refatoração serve justamente para isso, limpar continuamente a bagunça e deixar o código um local mais agradável de se trabalhar.