Várias empresas no nosso mercado tem produtos (desenvolvidos em casa ou comprados) que são mantidos dentro de suas próprias TIs. Neste processo de manutenção, estes produtos são evoluídos para incorporar gradativamente novas funcionalidades. Infelizmente, entretanto, estas evoluções são conduzidas com pouco ou nenhum processo. Estes remendos são repetidos dezenas ou centenas de vezes ao longo de vários meses ou anos. A aplicação sistemática do que chamamos de processo conserta e remenda gera, na grande maioria dos casos, sistemas completamente instáveis como um baralho de cartas.

Cito como exemplo dois casos que observei no último ano, em dois sistemas com código PL-SQL e C, respectivamente. No primeiro, observei algumas funcionalidades com milhares de linhas de código e um funcionalidade com mais de 10.000 linhas de código! No segundo sistema, em código C, observei o mesmo sintoma: algumas funções com milhares de linhas de código e várias outras com centenas de linhas de código.

Qual o problema, pode perguntar o leitor mais cético? Um código com funções deste porte leva frequentemente a produção de efeitos colaterais em suas manutenções devido a sua inerente complexidade e instabilidade. No sistema PL-SQL supracitado, um erro somente detectado em produção gerou um prejuízo (enorme!) na totalização mensal de seus processos de negócio. Após muito stress, acionamento de especialistas e muita confusão, o erro foi encontrado e sanado.

Técnicas para reduzir estas instabilidades existem há um bom tempo dentro da engenharia de software . Nos últimos dez anos, entretanto, vimos a formalização destas técnicas de melhoria de código e o surgimento de ferramentas de toda sorte para a análise e refatoração de código. A refatoração é a técnica de melhorar o desenho interno de um código ou produto de trabalho sem afetar as suas interfaces externas.

Sugiro dois sites primários para entender a arte da refatoração:

• Refactoring - Site mantido por Martin Fowler com um catálogo de boas práticas de refatoração de código e ferramentas de apoio a este processo.
• Database Refactoring: Site mantido pelo Scott Ambler com técnicas de refatoração de banco de dados para evitar que sucessivos remendos nos esquemas dos bancos em produção tornem os mesmos instáveis.

Sugiro, também, três livros chaves para trabalhar profissionalmente com refatoração:

• Refactoring - Improving the Design of Existing Code, Martin Fowler, Addison-Wesley 2004. (disponível em português)

• Refactoring Databases : Evolutionary Database Design, Scott Ambler, Addison-Wesley 2006.

• Working Effectively with Legacy Code, Michael Feathers, Object Mentor, 2005.

O último livro, aliás, é ideal para quem trabalha com manutenções adaptativas, corretivas e evolutivas no seu dia a dia.

Se você não quer ganhar códigos com milhares de linhas de código que ninguém consegue manter, considere praticar a refatoração como escovar os dentes ou tomar banho. Todo dia, faça chuva ou faça sol. Sessões de refatoração mantém o código limpo, saudável e sem os sintomas típicos que observo em várias empresas do nosso mercado: código duplicado espalhado pelos sistemas, código espaguete com alta complexidade ciclomática, acoplamentos desnecessários e baixa coesão entre funcionalidades e dados associados.

Cito, para terminar este pequeno artigo, um música sobre Refactoring, adaptada da música Hey Jude dos Beatles. (Mais músicas Nerds estão no site http://www.iconixsw.com/songsoftheextremos.html)

“hey dude” (c) Lyrics by Doug and Rob Rosenberg, ICONIX

hey dude
your code smells bad
go refactor and make it better
remember
that tests are requirements
then you can begin
to make it smell better

and if you say you need design
hey dude
don’t whine
make sure you don’t put in
any comments

just code what you need today
then go
and play
remember the schedule
is the customer’s problem

la la la la la, la la la laaaaaaa

hey dude
your code smells bad
go refactor and make it better
remember
that tests are requirements
then you can begin
to make it smell better