Do que se trata o artigo: Este artigo fala sobre refatoração e boas práticas na escrita de código. Serão apresentadas algumas analogias do software com nosso dia a dia para que se possa entender o quão problemático pode se tornar um código mal escrito. Além disso, serão apontados de forma bastante simples os problemas comumente encontrados na maioria dos softwares e como os métodos de refatoração podem ajudar.


Para que serve o artigo:
É uma etapa do desenvolvimento que serve para reestruturar o código de maneira que este fique mais limpo e expressivo. O objetivo desta prática é facilitar o entendimento do código existente para agilizar a adição de novas funcionalidades e correção de bugs.


Em que situação o tema é útil:
Recomenda-se que essa técnica seja praticada desde o início de um software, porém, ela se mostra bastante efetiva em casos onde o sistema já está em produção e que os desenvolvedores estejam passando por problemas para dar manutenção devido à dificuldade em entender e alterar o código

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.

Nota:

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.

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.

...
Quer ler esse conteúdo completo? Tenha acesso completo