Deve-se tentar aplicar a estrutura de uma solução para outros contextos, mesmo em escalas diferentes. É algo semelhante a proposta de padrões de projetos (Design Patterns) descrita por Gamma [GAMMA, 1995], onde estruturas de soluções eficientes para problemas freqüentes foram catalogadas para facilitar o reuso.

Por exemplo, uma prática básica na XP é escrever os testes antes da implementação das funcionalidades (seção 3.5.12). Esta prática dita um ritmo de desenvolvimento que opera em diferentes escalas.

No início de cada trimestre listam-se os temas (metas) que são importantes para o período e direcionarão as histórias do trimestre. Depois disto, os testes guiam diretamente o desenvolvimento em duas escalas:

1. Em cada semana, os usuários reunidos com os desenvolvedores priorizam e selecionam, entre as histórias, algumas para implementação. Então os testes que expressam estas histórias são escritos para depois serem colocados em funcionamento. Estes são os testes de aceitação (seção 5.2.2);

2. Em poucas horas é possível fazer uma lista com os testes necessários para uma funcionalidade. Então se escreve o código do primeiro teste e o coloca em funcionamento, depois o segundo é escrito e colocado pra funcionar junto com o primeiro, depois o terceiro e assim sucessivamente até que todos os testes da lista estejam funcionando. Estes são os testes de unidade (seção 5.2.1).

Auto-semelhança não é o único princípio que influencia o desenvolvimento de um software, pelo contrário, existem muitos outros. O fato de se copiar a estrutura de uma solução que funcionou bem em um ou mais contextos, não significa que ela irá funcionar sempre. De qualquer forma, é um bom lugar por onde começar. Em contrapartida, o fato de uma solução não ser reutilizável, não significa que esta seja ruim, pois existem casos onde esta é a melhor escolha [BECK, 2005].

Abraços,
Vinicius AC
Graduando – Univ. Federal de Sergipe