A solução para todos os problemas!

Depois de um longo período sem posts, vou retomar as atividades no blog contando uma experiência vivida por mim numa antiga equipe de desenvolvimento da qual fiz parte. Para quem acessa regularmente o blog, peço desculpas pelo hiato sem novidades aqui, e peço também que vocês me enviem solicitações dos padrões que gostariam que fosse abordado aqui no blog. Com o tempo, acabarei postando sobre todos os 23 padrões do GoF, mas “tempo” é um termo que está bastante escasso pra mim atualmente, então se tiverem interesse num padrão específico que gostariam logo de ver aqui, deixem-me saber, ok?

 A “experiência” que citei acima, numa equipe de desenvolvimento, diz respeito aos padrões de uma forma geral. Tudo começou quando nosso cliente estava reclamando de um erro que acontecia na aplicação, o conhecido erro da “submissão duplicada” no site: ele preenchia os campos e clicava no botão “Confirmar Cadastro”. Enquanto a transação se processava, e não tendo certeza se o cadastro seria mesmo efetivado, na dúvida ele clicava novamente em “Confirmar Cadastro”. Findo o processamento, ele percebia que o cadastro havia, de fato, sido efetivado... duas vezes!

Relatado o erro, nosso gerente convocou a equipe de desenvolvimento para uma reunião e quis ouvir sugestões dos desenvolvedores:

- Como resolver este problema?

Antes que eu pudesse emitir minha opinião, uma chuva de ideias, algumas mirabolantes, surgiu por parte dos meus colegas para corrigir a questão: “Coloca um aviso no site para clicar apenas 1 vez”, “Coloca no manual do usuário”, “Faz com que, ao clicar, ele vá para outra tela para confirmar o cadastro”, e a fantástica sugestão: “Depois que ele clicar 1 vez, a gente desabilita o botão”.

Sem entrar no mérito da criatividade dos meus colegas, várias questões vieram à tona pra mim: o que leva uma equipe a acreditar que esta é a primeira vez que alguém se depara com este problema na história da TI? Existem milhões de sistemas por aí, alguns levemente mais complexos que os nossos, e será que ninguém, nenhuma outra equipe de desenvolvimento neste planeta, em momento algum, passou por um problema parecido?

A resposta é: Sim, alguém já passou por isso! A menos que você trabalhe com algo bastante específico (e mesmo assim haveria controvérsias...), muito provavelmente outra equipe passou pelos mesmos problemas. Mais ainda: outra equipe muito mais competente, tecnicamente falando, não somente passou pelos mesmos problemas, como achou a melhor solução para cada um destes problemas, a solução mais robusta e mais performática! Por fim, esta equipe reuniu todas estas melhores soluções num catálogo pra você. A este catálogo, damos o nome de “Design Patterns”.

O título deste post diz respeito a isso. A solução para todos os problemas pode estar aí: procure um pattern! Problemas clássicos, rotineiros, do dia-a-dia, como o da submissão duplicada, como fazer paginação com cache, EJBs, otimização disto, daquilo, etc etc etc: Procure um pattern! 

Depois de ouvir muitas sugestões mirabolantes na reunião lá de cima, eu consegui mostrar aos meus colegas que “desabilitar o botão” poderia ser catastrófico. Caso o cliente pressionasse a tecla “Esc”, a submissão da página seria interrompida, o botão ficaria desabilitado, e toda a informação preenchida pelo cliente permaneceria no limbo para todo o sempre.

Felizmente pude apresentar o Synchronizer Token aos meus colegas, que adoraram a sugestão pela eficácia, pela simplicidade, e por terem aprendido algo novo, coisa que eu também adoro: aprender algo novo! Aprender algo novo e repetir boas soluções "velhas":
- Procurem um pattern, procurem um pattern..