Patterns e XP

Ainda traduzindo...

O exemplo do JUnit me leva inevitavelmente a trazer à tona os patterns. A relação entre patterns e XP é interessante, e é uma questão comum. Joshua Kerievky argumenta que patterns são pouco enfatizados em XP e ele coloca seu argumento eloquentemente, de modo que não preciso repeti-lo. Mas vale notar que para algumas pessoas patterns parecem ser conflituosos com XP.

A essência desse argumento é que patterns são frequentemente usado em excesso. O mundo está cheio de programadores legendários, frescos de sua primeira leitura do GOF que aplicam dezesseis patterns em 32 linhas de código. Me lembro uma tarde, movido por uma deliciosa puro-malte, planejando com Kent um artigo a se chamar "Not Design Patterns: 23 truques baratos". Estávamos imaginando coisas como usar um IF ao invés de uma estratégia. A piada tinha um fundo de verdade, patterns são frequentemente usados em excesso, mas isso não faz deles uma má idéia. A questão é como você os usa.

Uma teoria sobre isso é que as forças do design simples o levarão aos patterns. Muitos refactorings fazem isso explicitamente, mas mesmo sem eles, seguindo a regra do design simples, você chegará aos patterns mesmo que você ainda não os conheça. Isso pode ser verdade, mas será que essa é realmente a melhor forma de fazer isso? É claro que é melhor se você já souber de antemão aonde está indo e se tiver um livro que possa te ajudar com as dificuldades, ao invés de ter que inventar isso tudo por conta própria. Eu certamente ainda vou ao GOF sempre que percebo um pattern surgindo. Para mim o design efetivo implica que precisamos saber o preço que vale a pena pagar por um pattern - isso é sua própria habilidade. Similarmente, como Joshua sugere, precisamos estar mais familiarizados sobre como derivar um pattern gradativamente. A esse respeito XP trata o modo como usamos patterns de modo diferente do usual, mas certamente não remove seu valor.


Mas lendo algumas das listas de e-mail eu tenho o sentimento distinto de que muitas pessoas acham que XP desencoraja patterns, apesar da ironia que a maioria dos proponentes de XP foram lideres do movimento de patterns também. Isso é porque eles viram além dos patterns, ou porque os patterns estão tão impregnados em seus pensamentos que eles nem percebem mais? Eu não sei a resposta para os outros, mas pra mim patterns ainda são vitalmente importantes. XP pode ser um processo para desenvolvimento, mas patterns são a espinha dorsal do conhecimento sobre design, conhecimeno que é valioso tanto quanto o processo. Processos diferentes podem usar os patterns de modos diferentes. XP enfatiza tanto a não utilização de patterns até que eles sejam necessários como evoluir o código do seu modo derivando um pattern por meio de uma implementação simples. Mas patterns são ainda uma peça chave de conhecimento a se adquirir.

Meu conselho aos XPeiros usando patterns seriam:

* Invistam tempo aprendendo sobre patterns
* Concentrem-se em quando aplicar o pattern (não tão cedo)
* Concentrem-se em como implementar o patterns em sua forma mais simples primeiro, então adicione complexidade depois.
* Se você utilizar um pattern, e depois descobrir que não valeu a pena - não tenha medo de tirar ele fora de novo.

Eu acho que XP deveria enfatizar mais o aprendizado sobre patters. Não sei ao certo como encaixaria isso nas práticas de XP, mas tenho certeza de que o Kent pode descobrir um jeito.