Danilo Sato

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.

Este é o post de estréia do meu blog. Decidi escrever um blog para divulgar e compartilhar algumas das minhas experiências e idéias relacionadas ao desenvolvimento de software. Em especial, pretendo focar meus primeiros posts nas práticas de XP (eXtreme Programming), um dos mais conhecidos métodos ágeis de desenvolvimento.

Mas antes de entrar nos assuntos mais específicos, resolvi falar um pouco sobre o principal motivo que me levou a escrever um blog: Comunicação. A comunicação é o primeiro valor do manifesto ágil, que diz que “indivíduos e interações são mais importantes que ferramentas e processos”. O blog possui todos os componentes necessários para que a comunicação aconteça:

• Emissor, receptor e mensagem: Eu, você e o conteúdo do meu post. :-)
• Canal de propagação: a Internet, possibilitando que pessoas de qualquer parte do mundo possam compartilhar suas opiniões (a princípio só as que entendem português).
• Meio de comunicação: Escrita, que infelizmente nunca será um bom substituto para uma conversa.
• Resposta (Feedback): Deixe seu comentário que eu terei o prazer de responder e discutir suas opiniões.

Por fim, o nome do meu blog (“We can change!”) é uma alusão ao quarto valor do manifesto ágil – “resposta à mudança é mais importante que seguir um plano” – além de ser uma homenagem ao álbum conceitual “Be” de uma das minhas bandas preferidas, o Pain of Salvation.

Espero que aproveitem meu blog de alguma maneira e entrem em contato comigo caso tenham alguma dúvida ou sugestão para os próximos posts. Abraços e até a próxima!