Refactoring de Banco de Dados- SQL Magazine 81

As empresas de desenvolvimento de software têm evoluído constantemente. Muitas delas devem isto às novas e modernas metodologias ágeis que defendem a construção do software de maneira incremental e iterativa. Entretanto, disponibilizar sistemas de informação com qualidade em ciclos cada vez menores, ainda é uma missão desafiadora para muitas delas. Isto porque, é preciso garantir que a cada entrega, o sistema não perderá as suas funcionalidades e continuará sem erros. Além do mais, estas metodologias não prevêem a mesma iteratividade para o banco de dados. Para finalizar, algumas destas empresas ainda utilizam bancos de dados legados e não migram para sistemas mais novos por diversos motivos, dentre eles:

• Complexidade;

• Alto custo;

• Mudança de cultura da empresa;

• Falta de conhecimento dos desenvolvedores;

• Mudanças de paradigmas dos DBAs.

A boa notícia é que usando as técnicas de refactoring de banco de dados apresentadas neste artigo, é possível fazer estas migrações e melhorias de forma segura e incremental.

O antes e o depois

Até o final da década de 90, acreditava-se que a Engenharia de Software era similar a Engenharia Civil. No entanto, as necessidades do mercado mostraram que isto não era uma verdade absoluta. No modelo de desenvolvimento de software mais conhecido e praticado desta época – modelo cascata (Waterfall) – o DBA passava vários meses planejando e modelando o banco de dados, e este, ficava pronto antes mesmo da fase de desenvolvimento ter iniciado. O problema é que alterações no modelo do banco de dados, nos finais dos projetos, passaram a ser cada vez mais frequentes, dificultando a entrega (veja a Figura 1).

Figura 1. Modelo Cascata.

Pensando nisto, os consultores de informática: Pramod J. Sadalage e Scott W. Ambler criaram algumas técnicas para refatoração de banco de dados. Estas técnicas têm como base os mesmos objetivos das metodologias ágeis: minimizar o risco pelo desenvolvimento de software em períodos curtos, chamados de iteração, os quais duram de uma a quatro semanas. Cada iteração é como um projeto de software em miniatura, incluindo todas as tarefas necessárias para implantá-lo: planejamento,análise de requisitos, projeto, codificação, testee documentação.

É neste cenário que surge a figura do DBA ágil. Diferente do DBA comum, este participa de todas as iterações do projeto, planejando o esquema do banco de dados e apoiando a equipe de desenvolvimento.

Como se pode observar na Figura 2, o esquema do banco de dados é planejado e programado a cada iteração do projeto. O que significa que muitas vezes ele será alterado com o software já em produção.

Figura 2. Modelo Espiral.

O que é Refactoring?

Martin Fowler define refactoring da seguinte forma: “É um processo de alteração em um sistema de software, de modo que, o comportamento externo do código não mude, mas que sua estrutura interna seja melhorada.”.

O uso desta técnica aprimora a concepção (design) de umsoftwaree evita a deterioração tão comum durante o ciclo de vida de um código. Esta deterioração é geralmente causada por mudanças com objetivos de curto prazo ou por alterações realizadas sem a clara compreensão da concepção do sistema. Outra consequência é a melhora no entendimento do código, o que facilita a manutenção e evita a inclusão dedefeitos.

É fundamental que o sistema desoftwarepossua testes automatizados para realizar refatorações. Dessa forma será possível garantir que o comportamento externo não foi alterado."