Código legado. O Horror!!

Existem, na comunidade, várias definições para o que seria código legado: todo código que você escreveu é legado; o código que outra pessoa escreveu é legado; o código ruim, de difícil manutenção é legado. Não importando a definição, podemos identificar uma característica primordial, o código legado é aquele difícil de mudar. E isso, geralmente é um terror para os desenvolvedores.

Quem escreveu o código, não necessariamente é um desenvolvedor ruim. Precisamos entender o contexto. Mas gosto da idéia de que a qualidade do código é um espelho do local onde ele foi desenvolvido. Se o código é ruim, a empresa pode apresentar sintomas graves de uma péssima gestão, principalmente em se tratando de comunicação inter-departamentos, já que normalmente as demandas não vem de TI. Nesse cenário, será bem difícil trabalhar em melhorias do código legado, enquanto não houver melhorias nos processos internos da empresa e um alinhamento de negócios com TI. Mas, ainda assim, agente tenta.

Já tive a oportunidade de trabalhar em muitos projetos legados. Sei que você também tem muita história pra contar a respeito de suas aventuras nas matas densas do legado. Você irá achar que, a partir daqui, eu estarei exagerando e querendo causar polêmica, mas não, o que vou contar é a mais pura verdade. Já trabalhei com código que dava vontade de vomitar só de olhar pra ele. hahaha. Não é pra tanto, mas já chegou perto disso.

Trabalhei em projetos legados bem complexos e com uma base de código bem \\\’doente\\\’, normalmente monstros monolíticos. Mas apesar disso, os softwares eram, e são até hoje, bastante elogiados. Assim como para seres humanos o que importa é o caráter e não a aparência, para software o que importa é o valor que ele entrega ao cliente. Mas isso é só um lado da moeda. Aqueles sistemas tão elogiados de que falei faziam bem o seu trabalho, mas apresentavam uma base de código extremamente difícil de gerenciar, o que dificultava a criação de novas funcionalidades e melhorias.

Outro fator que considero importante em um cenário como esse é a satisfação com o seu trabalho. É bem ruim ter que trabalhar todo dia fazendo remendos em uma estrutura \\\’capenga\\\’. É desmotivante, é cansativo e isso pode aumentar a rotatividade em sua empresa. E a alta rotatividade de desenvolvedores é um fator que contribui a gerar mais código ruim. É extremamente frustrante quando, devido a algum fator, ou vários fatores, não é possível melhorar a base de código.

Você pode achar que isso tudo é muito mimimi. Mas que fique claro que o maior prejudicado nessa história é a empresa que mantém o código. Se não for possível fazer melhorias, a empresa terá que conviver com os custos de se manter um legado ruim. A escolha é sua, ficar no mimimi ou partir pro ataque.

Enfrentando o monstro

Uma outra definição para sistemas legados, e essa foi a que mais gostei, nos diz que sistema legado é todo sistema que não está coberto por uma suíte de testes, ou seja, você estará construindo código legado toda vez que você escreve código sem testes. Interessante. Então fica a dica: sempre que for refatorar, escreva um teste, se bem que refatorar sem testar não faz sentido. Mas quando se tem uma base de código muito grande e complexa, isso não é tão fácil. Além disso, você irá encontrar no legado muitos recursos que nem são utilizados. Puro lixo.

O código legado tem a característica de ser bastante acoplado. Então uma forma de começar a refatoração é isolando as dependências e trabalhar em cima delas. Inicialmente pode ser inviável criar testes de unidade, mas é possível criar testes de aceitação e isso pode ser um bom começo.

Outra forma seria o que Martin Fowler chama de estrangular a aplicação. Você vai criando um novo sistema nas bordas do antigo, muitas vezes de forma transparente ao usuário. Não é uma tarefa tão simples, principalmente se precisar rever a modelagem do banco de dados. É um processo bastante demorado e pode durar anos, mas é eficaz. É importante estar alinhado com a gerência e que ela saiba o que você está fazendo, mas algumas vezes é mais fácil pedir perdão do que permissão, essa é a verdade.

Um outro cenário é reescrever tudo. Isso pode ser possível, mas tem que ser analisado com cautela. Dependendo do contexto pode ser a melhor solução, ou pode ser catastrófico. Tive a experiência de trabalhar num sistema legado que estava até bem escrito. O problema é que ele havia sido desenvolvido com um framework caseiro que possuia geradores de código e o dono não estava mais na empresa. Não havia muito o que fazer. Resolvemos reescrever tudo com um novo framework que estávamos testando na época (um framework bastante conhecido e usado pela comunidade). Um fator que ajudou bastante é que a modelagem de dados do sistema legado estava impecável, então reaproveitamos o banco.

Uma dica final é sempre seguir padrões. Estar atento ao que a comunidade recomenda e participar de eventos é importante. Você pode estar sendo o vilão escrevendo o legado de amanhã. Poupe sua mãe de xingamentos. Lembre-se que o código não é seu, mesmo que você o tenha escrito.

referências:

Michael Feathers, Working Effectively with Legacy Code, Prentice Hall, 2005.

Martin Fowler, “StranglerApplication”, www.martinfowler.com/bliki/StranglerApplication.html.

Mary e Tom Poppendieck, Implementando o Desenvolvimento Lean de Software