Danilo Sato

In my last QCon presentation in São Paulo, I gave the audience my take on refactoring strategies. You can check out my slides from that talk on Slideshare (in Portuguese, but you should be able to follow the pictures and code samples).

One of my main points is that you need to learn how to shift between two levels of thinking when you engage in refactoring, each requiring you to develop different sets of skills. I called them: Mechanic vs. Strategic.

Mechanics is important because you should be doing small, incremental, and opportunistic refactorings all the time while you develop code. It’s not a coincidence that TDD has an explicit step of refactoring after you tests are green. In order to improve the design of your code you should master how to perform these small steps well. A lot of the modern IDEs – especially in static typed languages – provide great support for this and you should learn how to use them well.

On a strategic level, you have to be able to take a step back and understand the big picture of what you’re trying to achieve. While it’s important to know how to perform individual refactorings, it’s more important at this level to know how to compose them in order to achieve the design improvement you desire.

One of the examples I used to demonstrate this, was inspired by a blog entry that Paul Hammant published a few weeks before my talk. I got some feedback that it was hard to follow the code changes on the slides, so I decided to record a small video of me tackling his refactoring experiment.

In the following video, the strategy is not overly complex: extracting a few methods from a single controller into separate controllers. However, you will see how the order of steps you use can affect the refactoring, making your job harder or easier. You should also be able to pick up a lot of the mechanics along the way:

You can find some of my attempts in branches on this Github repository. If you want to try it out for yourself, or to take this experiment further, these are some of the things I would explore:

• The Upseller class should have it’s own tests, and I missed the @Component and @Scope("request") annotations that would probably be caught by integration tests.
• Using Mockito or some other mocking framework to mock collaborators, and adding more behaviour to the domain model objects since using toString for testing is not something I would particularly do in real life.
• Perhaps I could’ve used git stash instead of git reset to save the initial refactoring steps and later reapplying it assuming the merge would be simple.
• The path I took is not the only one and you can probably explore different refactoring steps and different approaches to get to the goal.

I would like to thank Paul Hammant for coming up with this experiment and for encouraging me to publish this screencast. Please send me some feedback if you think this was useful or helpful for you!

Clique aqui para ler em Português

I’m excited to be going to Fortaleza at the end of this month to present and organize Agile Brazil 2011. Last year in Porto Alegre I decided to focus on the organization aspects of the conference, but this year I decided to present again. Even though I’ve been participating in conferences around the world, my last talk in Brazil was in 2008 and I really miss being around the Brazilian community and sharing experiences with everyone. That’s why I’m happy to be presenting in (mostly) Portuguese again :-)

Managing your technical debt – June 29th

In this 50 minutes talk, I will cover a few practices and ideas I’ve used and seen used in projects to manage technical debt responsibly. Some of the topics I will cover are:

• What is technical debt and what are the consequences of incurring it
• Ideas on how to identify “hot spots”
• How to prioritize and plan the payment of your debt
• Tracking and visibility
• How to avoid incurring debt
• Communicating the importance of paying technical debt to non-technical managers and stakeholders

Slicing and dicing your user stories – July 1st

Co-presenting with Jenny, in this 50 minutes talk we will discuss the benefits of working with small user stories, and present different ways to split requirements into user stories. The session will cover topics related to:

• What makes good user stories
• How to break down features into smaller chunks without losing track of the overall goal
• Different ways to split stories into vertical slices
• Helping stakeholders to track and understand how the feature will be delivered piece by piece
• Planning the delivery to increase feedback

Refactoring Katas – July 1st

In this 10 minutes Lightning Talk, I’ll share an idea I’ve been using to practice refactoring. Using a different Kata format, I will explain the mechanics and quickly demonstrate it in practice.

If you haven’t registered yet, you can still register online. And if you are around Rio and São Paulo the following week, I will be giving ThoughtWorks’ AWS Training, which you can register here. I’m looking forward to seeing you in Fortaleza!

Agile Brazil 2011 – Eu vou!

Estou empolgado com a viagem para Fortaleza no final do mês para participar e organizar a Agile Brazil 2011. No ano passado em Porto Alegre, eu decidi me focar mais na organização do evento, mas esse ano resolvi apresentar. Mesmo estando participando de diversas conferências ao redor do mundo, minha última palestra no Brasil foi em 2008 e eu sinto saudade de estar compartilhando experiências com a comunidade brasileira. É por isso que estou feliz por apresentar (na maior parte) em Português novamente :-)

Gerenciando sua dívida técnica – 29 de Junho

Nessa palestra de 50 minutos, eu vou apresentar algumas idéias e práticas que tenho usado para gerenciar dívida técnica de forma responsável. Alguns dos tópicos que irei abordar:

• O que é dívida técnica? Quais os sintomas mais comuns e qual as consequências do acúmulo de dívida técnica?
• Formas de identificar e encontrar “hot spots”
• Como priorizar e planejar o pagamento da dívida
• Tracking e visibilidade
• Como evitar o acúmulo
• Idéias para convencer gerentes e pessoas sem conhecimento técnico sobre a importância de pagar a dívida

Slicing and dicing your user stories – 1 de Julho

Apresentado junto com a Jenny, essa palestra de 50 minutos vai discutir os benefícios de usar user stories pequenas e apresentar diferentes formas de dividir requisitos em histórias. A palestra vai cobrir tópicos sobre:

• Características de boas user stories
• Como quebrar funcionalidades em pedaços pequenos sem perder a visão do todo
• Diferentes idéias para quebrar requisitos em fatias verticais
• Formas de ajudar stakeholders a rastrear e entender como uma funcionalidade será entregue em pedaços menores
• Planejamento da entrega para maximizar o feedback

Refactoring Katas – 1 de Julho

Nessa Lightning Talk de 10 minutos, vou compartilhar uma ideia que tenho usado para praticar refatoração. Usando um formato de Kata diferente, vou explicar a mecânica do exercício e demonstrar um pouco como ela funciona na prática.

Se você ainda não se inscreveu, ainda pode se inscrever online. E caso esteja por perto no Rio e em São Paulo na semana seguinte, estarei ministrando o Treinamento AWS da ThoughtWorks, que você pode se inscrever aqui. Vejo vocês em Fortaleza!

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 um
livro
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?

A grande fonte de dificuldade quando você precisa lidar com código legado é que ele está muito acoplado ou dependente
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”

Nesse post falaremos um pouco sobre alguns dos mitos relacionados ao design em XP e sobre a nova abordagem de Kent Beck para garantir a qualidade e a simplicidade do design de um sistema.

Na primeira edição do livro Extreme Programming Explained, Kent Beck propôs 3 práticas que estavam diretamente relacionadas ao design do sistema: Design Simples, Refatoração e Metáfora. Dessas três, a última é a que mais gerou confusão nos praticantes de XP, sendo uma das menos utilizadas na prática. Com relação às outras duas, já ouvi diversas críticas e dúvidas:

• Como garantir que estou sempre implementando a idéia mais simples para resolver meu problema?
• Quais os fatores para determinar a simplicidade do meu código?
• Evitar BDUF (Big Design Up-Front) significa nunca pensar no design?

Algumas dessas dúvidas estão relacionadas à forma como elas foram apresentadas na primeira edição, enquanto outras se baseiam numa interpretação errônea da prática no contexto de XP. A resposta para essas perguntas está melhor estruturada numa nova prática da segunda edição do livro: o Design Incremental. Invista no design do sistema um pouco a cada dia e se esforce para que o design seja excelente para resolver as necessidades atuais do sistema.

• Quando?: Ao contrário de pensar pouco ou nunca pensar no design, a estratégia de XP é pensar sempre no design.
• Como?: Faça mudanças em passos seguros e pequenos. A disciplina que facilita a evolução constante do design em XP é a refatoração, que melhora a qualidade do código sem alterar o comportamento do sistema.
• Onde?: A heurística mais simples e eficaz é eliminar código duplicado. Adicionar uma feature num único lugar é muito mais simples e rápido do que ter que mexer em código espalhado por diversas classes.
• Por quê?: Um design simples é mais comunicativo e mais fácil de ser entendido e alterado. Se o objetivo de XP é manter o custo da mudança constante, a facilidade de alterar o design a qualquer momento é fundamental.

Os novos critérios propostos por Kent Beck para avaliar a simplicidade são, em ordem de prioridade:

1. Apropriado para o público-alvo: O código deve ser facilmente entendido pelas pessoas que vão trabalhar com ele.
2. Comunicativo: Todas as idéias e intenções devem estar presentes no código, facilitando o entendimento do time e de um futuro leitor.
3. Fatorado: A existência de código duplicado dificulta as alterações e o entendimento.
4. Mínimo: Cumprindo as três restrições acima, um sistema deve ter o menor número de elementos possível. Menos classes implicam em menos código para testar, documentar e comunicar.

Para auxiliar o entendimento dos critérios de XP para avaliar e produzir código de qualidade, uma outra prática – que a princípio não parece ter relação direta com o design – se mostra muito importante: o Desenvolvimento Orientado a Testes (TDD – Test Driven Development). Ela será o tema dos próximos posts e, ao contrário do que possa parecer, está tão relacionada à produção de testes automatizados quanto à produção de código mais simples, comunicativo, fatorado e mínimo.