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.
