IGTI Blog
Refatoração

Refatoração de código-fonte: sucesso e fracasso em uma mesma tarefa

Como o processo de refatoração de código, feito de maneira correta pode trazer benefícios e como o contrário pode trazer enormes transtornos?

Um dos “papas” da refatoração de código, Martin Fowler, conceituou em seu livro intitulado “Refatoração – Aperfeiçoando o Projeto de Código Existente”, que a refatoração é o processo de modificar um sistema de software para melhorar a sua estrutura interna de código-fonte sem alterar o seu comportamento externo. Esse livro e essa afirmação vem sendo seguida à risca por muitos dos desenvolvedores de software, analistas de sistemas e engenheiros de software em todo o mundo.

O problema encontrado nessa afirmação e que será tratado nesse post, diz respeito a real aplicabilidade dessa técnica no dia-a-dia dos desenvolvedores de software moderno. Como encaixar essa prática importante em nossa vida real, ou seja, em prazos apertados, projetos atrasados, cronogramas irreais, clientes estressados e gerentes de projeto à beira de um ataque de nervos?

Nesse post vamos apresentar os benefícios da refatoração e também a sua aplicabilidade, que de antemão podemos dizer: é uma responsabilidade de todos os profissionais que estão envolvidos em um projeto de software e tem a possibilidade de trazer bons resultados.

Benefícios da Refatoração

É inegável que a refatoração de código traz benefícios para o desenvolvimento de software. Poderíamos escrever páginas e mais páginas detalhando esses benefícios e seus reais impactos no custo e prazo de um projeto. Resumidamente, podemos apontar os dois principais benefícios, que sozinhos já seriam suficientes para justificar a utilização da técnica:

           1. Melhor entendimento do código:

Sabe aquele código que, de tão complexo, só você entende? Ou aquele método que, devido ao prazo apertado, não deu tempo de colocar na classe correta? E aquele recurso técnico necessário que foi inserido para solucionar um problema que estava impossibilitando a utilização do sistema e estava deixando o usuário louco?  Pois é, durante a refatoração é quando procuramos eliminar esses pontos e, com isso, melhorar o entendimento do nosso código, para que futuras gerações de desenvolvedores possam dar manutenção nele.

          2. Facilidade de Manutenção

Esse benefício está diretamente ligado ao anterior. Inevitavelmente um software vai precisar de manutenções ao longo de seu ciclo-de-vida, seja por novos requisitos, por mudanças das regras ou por atualização tecnológica. Podemos dizer que não existe nada mais complicado de fazer do que uma manutenção em um código-fonte de difícil compreensão. Diante disso, a refatoração auxilia no melhor entendimento do código, que por sua vez traz maior facilidade de manutenção.

Outros benefícios podem ser alcançados com a refatoração, como a possibilidade de aprendizado que essa técnica pode trazer para programadores menos experientes. Ao refatorar, os programadores podem ir adquirindo conhecimento gradativo sobre as regras que regem o sistema e, com isso, adquirirem mais experiência para futuras implementações. Além disso, ao refatorar um código podemos acabar encontrando alguns defeitos que estavam “escondidos” e temos a oportunidade de consertá-los antes que algum cliente o encontre.

O processo de refatoração, para funcionar corretamente e trazer os benefícios esperados, precisa ser praticado em todas as circunstâncias. É necessário que a técnica seja abraçada por todos os envolvidos no processo de construção de software, como engenheiros, analistas, desenvolvedores, testadores e a gerência. O processo de software da empresa precisa ser alterado (e respeitado) para que sejam introduzidas etapas que disciplinem a refatoração. Por outro lado, os projetos precisam prever em seus cronogramas, tempo para a realização dessa tarefa.

Refatoração na vida real

Muito bem. Já falamos sobre os benefícios da refatoração e também sobre a necessidade de apoio de todos para o perfeito funcionamento da técnica. Poderíamos parar por aqui e concluir que, se implantado da forma que sugerimos, a refatoração trará enormes benefícios e resolverá quase todos os problemas de uma empresa desenvolvedora de software, entretanto a realidade é um pouco mais complicada que isso.

Muitas organizações possuem regras em seus processos que formalizam a refatoração, mas o que acontece com essas regras quando o projeto atrasa? O que acontece com essas regras quando o maior cliente da empresa pede urgência? Além disso, existe um tabu muito forte entre os desenvolvedores de software, que é: onde arranjar coragem suficiente para refatorar uma parte crítica do código, onde temos um código-fonte malfeito, mas que funciona?

Em muitos anos de experiência na área de desenvolvimento de software, tenho convivido diariamente com essas questões e posso dizer que conheci muitos desenvolvedores com ótima técnica que diziam: não mexa no que está quieto. Se está funcionando, não vá caçar chifre na cabeça de cavalo! Ou ainda, quem em sã consciência mexeria nessa funcionalidade do sistema que é a mais complexa? Deixe como está. Por outro lado, já convivi com gerentes de projeto que diziam: não há tempo para refatoração. O cronograma está apertado e, se tivermos que cortar, será na tarefa prevista para a refatoração.

É plenamente possível entender o lado desses dois profissionais, o desenvolvedor e o gerente de projeto. Como desenvolvedor, a possibilidade de inserirmos mais problemas que soluções durante a refatoração é enorme e sabemos quem vai consertar o sistema quando o problema for encontrado. Como gerente de projetos, é difícil justificar para o cliente um atraso proveniente de uma refatoração, pois essa técnica não traz resultados visíveis para o cliente. A refatoração não pode alterar o comportamento do sistema, pois se o fizer deixará de ser refatoração e se tornará uma modificação. A refatoração, mesmo não alterando o comportamento do software, precisa ser testada para comprovar que não inseriu nenhum defeito no sistema e isso demandará mais tempo ainda.

Engenheiros de Software têm uma grande dificuldade em justificar para os gerentes de projeto menos técnicos e para a diretoria, o custo e o tempo gastos com a refatoração. Essa técnica demanda várias horas de desenvolvedores que ficam em busca de maneiras para tornar o código-fonte ainda melhor, e de testadores que precisam garantir que o software não sofreu alterações em seu comportamento. Como todos sabemos, horas de desenvolvimento custam muito dinheiro e é uma variável com peso muito alto no custo total do projeto. É necessário um grande malabarismo para demonstrar que o recurso gasto agora com a refatoração será pago muitas vezes lá na frente quando o software estiver ainda mais abrangente, complexo e de difícil manutenção.

Preciso destacar que já convivi com muitos desenvolvedores e gerentes de projeto que são verdadeiros entusiastas da refatoração, principalmente aqueles que já colheram algum fruto proveniente dessa técnica. Esses profissionais têm a tarefa de refatoração como uma constante ação no dia-a-dia e a aplicam o tempo todo.

Então? Devemos refatorar ou não?

Não existe fórmula mágica para implantar a refatoração na cultura da organização. O que fazemos incansavelmente é tentar demonstrar o custo-benefício da refatoração no médio e longo prazo, e desmistificar alguns pensamentos e preconceitos de desenvolvedores e gerentes de projeto, conforme apresentamos acima. Lembramos que esses pensamentos são plenamente compreensíveis diante da realidade do desenvolvimento de software que vivemos.

A cultura da refatoração é implantada de grão em grão. Inicialmente precisamos do apoio e compreensão da direção. Se essa direção não possuir um pensamento proativo e de longo prazo, a possibilidade de fracasso ou de descumprimento das regras do jogo é muito grande. Após conquistarmos esse apoio, entra em ação um plano para convencer os desenvolvedores a mexerem no que está quieto, mas com responsabilidade e senso de melhoria contínua.

Por último cabe o convencimento dos gerentes de projeto. É importante mostrar que a refatoração não é um custo, mas sim um investimento que trará frutos no futuro, e esse futuro muitas vezes não é muito distante e pode estar dentro do próprio projeto em curso. Normalmente, quando um gerente de projeto passa pela experiência de viver um benefício trazido pela refatoração dentro de um de seus projetos, ele nunca mais esquece e muitas vezes se torna um defensor da causa.

Então diante de toda essa discussão, a minha opinião final é que se fizermos a refatoração da maneira como manda o figurino, ela costuma valer muito a pena. Mas que maneira correta é essa afinal? Primeiramente, o apoio da alta direção e comprometimento de toda a equipe. Depois, a quebra de algumas resistências que vários profissionais ainda possuem. Por último, apresentação dos resultados da refatoração para que todos possam tomar conhecimento dos seus benefícios. A refatoração é um caminho sem volta rumo à um código bem escrito, de qualidade, menos complexo e de mais simples manutenção.

Professor autor: João Paulo Barbosa Nascimento