01 novembro 2008

As práticas habilitadoras de XP

Continuando a série... ( a propósito, há alguma tradução melhor para "enabling practices" ? )

XP é controversa em muitos sentidos, mas uma das bandeiras vermelhas em XP é que ela advoga design evolutivo ao invés de design planejado. Como sabemos, design evolucitivo não pode funcionar devido ás decisões ad hoc e à entropia de software.

Na raiz do entendimento desse argumento está a curva de mudanças do software. A curva de mudanças diz que, à medida que o projeto decorre, torna-se exponencialmente mais caro fazer mudanças. A curva de mudanças é normalmente expressa em termos de fases "uma mudança feita durante a análise por $1 custaria milhares para consertar em produção". É irônico que a maioria dos projetos ainda trabalhe em um processo ad-hoc que não possui uma fase de análise, mas a exponenciação ainda está lá. A curva de mudanças exponencial significa que o design evolutivo não pode funcionar. Também indica o motivo pelo qual o design planejado precisa ser feito cuidadosamente, porque qualquer erro no design se depara com a mesma exponenciação.


A premissa fundamental a respeito de XP é que é possível nivelar a curva o suficiente para fazer o design evolutivo funcionar. Esse nivelamento é tanto habilitado por XP como explorado por XP. Isso é parte do acoplamento existente entre as práticas de XP: especificamente não se pode fazer aquelas partes de XP que exploram a curva nivelada sem fazer aquelas que habilitam o nivelamento. Essa é uma fonte comum de controvérsia sobre XP. Muitas pessoas criticam a exploração sem entender a habilitação. Frequentemente as críticas surgem da própria experiência dos críticos onde não usaram as práticas habilitadoras que permitam que as praticas exploradoras funcionem. O resultado é que eles se queimam e quando vêem XP eles lembram das chamas.

Existem muitas partes para as práticas habilitadoras. No centro estão as práticas de Testes e Integração Contínua. Sem a segurança provida pelos testes, o resto de XP seria impossível. Integração contínua é necessária para manter a equipe em sincronia, de modo que se possa fazer mudanças sem aborrecimentos para integra-la com os outros. Juntas essas práticas podem ter um grande efeito na curva de mudanças. Me recordei disso mais uma vez aqui na ThoghtWorks. Introduzir testes e integração contínua trouxe melhoras significativas no esforço de desenvolvimento. Certamente o suficiente para questionar a assertiva de XP de que você precisa de todas as práticas para obter uma grande melhoria.



Refactoring possui um efeito similar. Pessoas que refatoram seu código da forma disciplinada sugerida pela XP vêem uma diferença significativa em sua efetividade compara a fazer reestruturações de forma mais frouxa e ad hoc. Essa foi minha experiência quando Kent me ensinou a refatorar corretamente. Afinal, apenas uma mudança forte me motivaria a escrever um livro completo sobre isso.

Jim Highsmith, em seu excelente resumo sobre XP, usa a analogia de um conjunto de escalas. Em uma bandeja está o design planejado, na outra refactoring. Em abordagens mais tradicionais o design planejado domina porque a premissa é que não se pode mudar de idéias depois. À medida em que o custo das mudanças diminui, você passa a poder fazer a maioria do seu design mais tarde como refactoring. O design planejado não some completamente, mas agora existe uma balança de duas abordagens de design para se trabalhar. Pra mim, é como se antes do refactoring eu estivesse fazendo todo o meu design com uma mão só.


Essas práticas habilitadoras de integração contínua, testes e refactoring provêem um novo ambiente que torna plausivel o design evolutivo. Entretanto, uma coisa que ainda não conseguimos visualizar é para onde a balança deve apontar. Tenho certeza de que, tirando a impressão de quem está de fora, XP não é apenas testa, codifica, e refatora. Existe espaco para projetar antes da codificação. Parte dele se faz antes de se existir qualquer código, a maioria ocorre nas iterações antes de codificar uma tarefa em particular. Mas existe uma nova balança entre o design up-front e o refactoring.

Nenhum comentário:

Postar um comentário