July 27th, 2006Agile 2006 – Dia 5
No último dia da conferência também estava cheio de trabalho agendado na parte da manhã e na parte da tarde.
As duas últimas sessões que participei foram também muito interessantes: refatoração de banco de dados e técnicas
eficientes para trabalhar com código legado. Para finalizar, uma última palestra no banquete servido a noite.
Refactoring Databases: Evolutionary Database Design – Scott Ambler e Pramod Sadalage
Essa palestra foi muito interessante. Ambos os apresentadores acabaram de lançar umlivro
sobre o assunto e falaram sobre como as pessoas do mundo dos bancos de dados estão atrasadas
em relação ao mundo “ágil”. Poucas ferramentas
existem para teste em banco de dados e, conforme os autores
comentaram, os bancos de dados relacionais já estão no mercado há muito tempo. Eles lançaram uma pergunta desafiadora:
“Você acha possÃvel fazer uma mudança trivial no seu banco de dados atual, como mudar o nome de uma coluna, e implantar
essa mudança em produção no dia seguinte?”. Muitos dos presentes achavam muito difÃcil fazer essa simples mudança nas
empresas onde trabalham. Scott Ambler está
lançando uma série de pesquisas no site do Dr. Dobb's e uma delas é sobre
banco de dados ágeis. Os resultados serão publicados em Novembro e os dados estarão disponÃveis no
site dele, porém ele disse que, apesar da maioria das pessoas afirmarem que
as informações armazenadas no banco de dados são consideradas ativos da empresa, poucos têm uma estratégia
para recuperação e manutenção dos dados em produção.Durante o tutorial, Pramod mostrou exemplos de como trazer a evolução do
banco de dados para seu sistema de controle de versão (CVS, SVN, …) e como executar algumas das
refatorações propostas, integrando tudo com Ant e
Cruise Control.Devemos dar a devida atenção para a integração entre as 2 comunidades (banco de dados e a comunidade ágil),
pois essa será uma área que receberá grande atenção nos próximos anos. Acredito que através da colaboração conjunta,
existe um grande potencial para o surgimento de novas ferramentas e processos que devem mudar a perspectiva
das empresas em relação ao assunto. E isso não deve acontecer num futuro tão distante. Para finalizar, uma foto
com os apresentadores:
Working Effectively with Legacy Code – Michael Feathers
Na parte da tarde eu fui auxiliar a sessão do Michael Feathers sobre o livro homônimo“Working Effectively with Legacy Code”.
O tutorial começou com a sua definição de código legado: “Todo código que não tem teste”. Muito boa essa definição.
O resto da palestra foi sobre técnicas para conseguir colocar pedaços de código existentes numa suite de testes. Grande
parte do desafio nessa tarefa é conseguir instanciar objetos numa suite de teste, evitando operações
demoradas ou efeitos colaterais indesejados num teste de unidade. Alguns dos critérios que Michael propôs para saber quando
um teste de unidade não é eficiente são:
- O teste fala com o Banco de Dados
- O teste faz algum tipo de comunicação na rede
- O teste fala com o Sistema de Arquivos
- O teste não pode ser executado ao mesmo tempo que outros testes (dependência entre testes)
- Você precisa fazer alterações especiais no ambiente para poder executá-los
De modo geral, ele não quis dizer que você não deve testar coisas como acesso ao Banco de Dados ou Sistema de Arquivos,
mas sim que essas coisas fazem seu teste de unidade demorar para rodar. Testes de unidade devem rodar rápido. Ou melhor:
você considera o Banco de Dados parte da “unidade” que está testando?
de outras partes do código, tornando difÃcil instanciá-lo independentemente do resto no seu teste.
Michael mostrou
diversas técnicas para quebrar tais dependências. Refatorar o código para melhorar o design e diminuir as
dependências é algo inseguro, por isso a refatoração depende tanto da suite de testes: ela é sua rede de segurança
para evitar que as coisas quebrem. Porém, ao lidar com código legado, é difÃcil saber se você quebrou alguma outra
coisa, pois os testes não estão lá para te ajudar. Por isso as técnicas mostradas no tutorial são muito cuidadosas,
compostas de pequenos passos seguros onde as chances de quebrar são muito pequenas. Pode ser que seu código fique
mais feio para conseguir escrever o teste. Porém, uma vez que seu código está “cercado” por testes, você tem
segurança para começar a mudá-lo e melhorá-lo, levando-o em direção a um design mais robusto.
Engineering Outside the Box – Greg Harbaugh
O dia e a conferência terminaram com um banquete na parte da noite, com muita comida, bebida,cowbells e colares brilhantes:Durante o banquete, Greg Harbaugh, um ex-astronauta, deu uma palestra inspiradora sobre a forma com a qual
encaramos nossos problemas. Após a palestra, foram apresentados os ganhadores do prêmio
Gordon Pask desse ano, um prêmio entregue
para lembrar e recompensar as pessoas que contribuÃram para o movimento ágil durante o último ano.Essa foi a primeira vez que fui a uma conferência e foi uma experiência incrÃvel. Durante esses 6 dias eu aprendi
muita coisa, conheci muita gente (não é todo dia que você almoça do lado do Martin Fowler)
e fiquei realmente inspirado com as idéias e valores do movimento ágil. Mais do que assistir palestras dos
autores que admiro, eu consegui apreciar por completo o valor da existência de uma comunidade que suporta e
promove os mesmos valores. São pessoas que realmente gostam e acreditam naquilo que fazem e trabalham para
elevar o estado da arte da nossa profissão. Termino com uma frase dita por um dos ganhadores do prêmio desse ano,
Laurent Bossavit:“Devemos continuar trabalhando para fazer da nossa profissão algo tão nobre quanto a profissão do bombeiro ou do astronauta”