Blog do Andre Fonseca

Em desenvolvimento de sistemas uma das modas, num aspecto mais técnico, é o uso maciço de Padrões de Projeto (Design Patterns).  Chega a ser excessivo, em minha opinião e por isso, seu uso, ao invés de ajudar no projeto, atrapalha e cria verdadeiros monstros (impossíveis de entender, dar manutenção, modificar, compreensão do que está sendo feito difícil, etc). Projetos sem padrões é algo um tanto desordenado, mas projetos com uso exagerado ou de forma “incorreta” torna um sistema um elefante branco.

Por volta de 1995, o GoF (Gang of Four – Erica Gamma, Richard Helm, Ralph johnson, John Vlissides), publicou um livro intitulado : “Design Patterns – Elements of Reusable  Object-Oriented Software”.  Devido a ele, a questão dos padrões de projeto ganhou popularidade e partir de então passou a ser quase que uma obrigação a quem se aventurasse a desenvolver conhecer alguma (as vezes todas) das soluções proposta no trabalho do GoF.  Fiz várias entrevistas nas quais me perguntaram se conhecia Patterns; pediram para explicar e desenhar  algum em particular; e por ai foram.

Padrões não são ruins. Como vários sites e artigos dizem: esses padrões foram soluções de sucesso e testadas ( ou seja, comprovadamente ela funciona e tem um bom desempenho dentro do cenário que ela se propõe) que alguém fez e resolveu catalogar para que no futuro, alguém ao se deparar com um problema de mesma natureza saiba pelo menos um ponto de partida.  De forma bastante simplista, esse catálogo é uma fonte de consulta e onde podemos nos basear, entretanto, não devemos encará-lo como sendo uma verdade absoluta e que não usar o padrão proposto, sem quaisquer alterações,  é um heresia.  Todo o radicalismo independente do lado que penda é ruim. O radicalismo de alguns em dizer que patterns são besteiras e os dos que dizem somente eles devem ser usados não , na minha forma de ver as coisas, o melhor caminho para seguir se desejarmos fazer códigos de qualidade.

Eric Freeman e Elisabeth Freeman em seu livro “Head First Design Patterns ” (Em português o título do livro é : Use a Cabeça Padrões de Projeto), são um ar fresco  e trazem uma nova luz sobre o assunto. Num edição impecável e bem escrita, eles resgatam a questão do uso de padrões do radicalismo e tentam e forma simples mostrar porque devemos pelo menos conhecê-los.  O livro vai direto ao ponto e muitas de suas ideias estão de acordo como vejo o tema.

Um primeiro ponto é que para mim não existe verdade absoluta : um padrão não é e nunca será a única solução para um determinado problema. A diferença está, como já disse antes, que o catalogado é de domínio público (facilita a quem terá que entender o sistema depois), testado e já obteve sucesso em sua aplicação.  De novo, insisto, não é a única opção e pode até, dependendo do caso, não ser a melhor.  Existem diversos fatores a considerar na escolha de um padrão para usar: escopo, custo, tempo, recursos, etc. Como exemplo gosto de citar um caso onde uma pessoa deveria fazer uma aplicação web. Ela teria apenas 4 telas : uma de login, uma para fazer importar uma planilha excel, uma para visualização de dados, etc… O desenvolvedor  acabou, por pura preciosismo usando patterns em quantidades generosas… resultado: tudo ficou um lixo e colocaram a culpa do cara que sugeriu que usassem uma tecnologia de ponta (Struts e Hibernate)

Segundo ponto:  aprender padrões é aprender a se comunicar. Ao aprender os padrões você está adquirindo uma linguagem, de certa forma. Assim, quando quiser explicar a um desenvolvedor do time que poderia fazer de um jeito, sendo ele um pattern, basta que diga : “Fulano vamos usar o pattern XuxaSbrbublesIce++”.Sei que isso pode parecer radical (justo o que critiquei antes) porém se observarmos de um outro angulo a coisa realmente faz sentido

Terceiro : Em alguma parte antes disse que padrões devem ser usados como ponto de partida. O problema está que a maioria das pessoas usa como objetivo. Acredito que muitos serão os casos em que terei que usar uma implementação da forma que o livro ensina, entretanto, haverão tantos outros que terei que adaptar, misturar, usar parte, etc.

Bom agora vai minha opinião:

Conhecer design pattern é bom mesmo que seja para falar mal enquanto toma cerveja com os amigos num #horaextra. Fora isso, ao conhecê-lo você começa a abrir sua cabeça para novas possibilidades e formas de resolver problemas.

Recentemente li um artigo do Martin Fowler (já tinha lido, mas praticamente o reli com outros olhos)  onde ele discute a questão do design e da análise dentro do mundo ágil, mais precisamente o XP (Extreme Programming).  No artigo, cujo título é “Is Design Dead?”, Fowler discorre sobre vários tópicos e tenta ver se é realmente um fato que com a adoção de  metodologias ágeis, o uso de padrões, análise prévias e design se tornaram práticas mortas

Dentro do times ágeis, existem diversas premissas que devem ser adotadas para que se possa colher todas as vantagens que ele oferece.  Algumas das mais famosas são:

• Faça o justo necessário:  não faça aquém nem além do que deve ser feito na iteração
• Refatoração : sempre que puder melhore o código
• Foco nas tarefas que agregam valor na visão do cliente
• Fazer o simples e depois evoluir o código de acordo com a necessidade.

Fazer o justo necessário é de focar em gerar valor para o cliente. Aqui a principal mensagem está em evitar tarefas que no final não geram retorno. Exemplo: o tme que gasta horas para criar um modelo de dados;  times que gastam considerável soma de tempo para escrever  bibliotecas para fazer algo que não esteja ligada a funcionalidade que o cliente deseja  naquela iteração (api de log, api de para ler o xml de configuração, api para tratar string, etc). Nesta ideia também se encaixa a questão de evitar tarefas que não agregam valor para o produto.

A Refatoração constante do código significa mais que simplesmente rescrever trechos de código e sim, uma busca constante por simplicidade, qualidade e por programas legíveis. Uma coisa que os mais novos sempre erram é de ter uma visão simplória do que venha ser Refatorar : não é simplesmente acerto de escopo de variável,  comentar, etc.  Refatorar, em XP principalmente é “alma do negócio”.

Quando se diz – ” Fazer o simples e evoluir“, você está comunicando ao seu time que é desejável que façam coisas simples. A medida da necessidade do projeto, os modelos, arquiteturas, etc., vão evoluindo e ganhando os recursos necessários para resolver os problemas.  Dentro da refatoração existirá, também, o espaço necessário para a melhora.

Fazer ou não fazer análise em projetos ágeis ?

Diante do que disse antes, principalmente de evitar atividades que não agreguem valor, os mais puristas, diriam que fazer analise ( estudo, diagramas, etc para entender a arquitetura e quais seriam os requisitos técnicos)  é algo que não deve ser feito. Iriam além estes mesmo: afirmaria que tal prática é ultrapassada e que de nada server.

Bom, eu discordo. E se me perguntassem isso, responderia:  - “Depende ! “

Se estamos falando de um sistema simples, cujos os requisitos são extremamente claros,  fazer analise pode ser um passo a mais que poderia ser retirado. Ou então, considerado como um história de documentação que deve ser tratado no backlog ( mas com baixa prioridade de acordo com a visão do cliente). Porém se estamos falando de sistemas cujo o processo a ser gerido é complicado  e/ou com regras de negócios complexas, uma fase, por menos que seja, de análise ajudaria até melhor entender os requisitos. O problema está que muitas equipes de desenvolvimento tornam o resultado de uma analise uma verdade absoluta e imutável.  Bem, isso não pode ser verdade pois o cliente vária vezes nem ter certeza do que quer e ao longo das entregas que começa a desenhar melhor sua necessidade e desejo.

Analisar previamente ajuda a diminuir riscos e a nortear, de certo modo, a visão do time na hora de implementar.

Entretanto, ao realizar uma analise, podemos pensar como um rascunho do Niemeyer de um prédio novo. Serve apenas para ter um impressão inicial não muito clara do que iremos realizar.

Quem usa XP não adota padrões?  Não define arquitetura?

Esta aí outra coisa que não gosto e nem concordo em ouvir.  Bem, os padrões não são ruins, são as pessoas que abusam do direito de usá-los.  Já vi gente fazendo um site para 10 pessoas (coisa interna de uma empresa) cujo o escopo é limitado e quase nunca evolui, colocando milhões de camadas, milhares de DAOs, VOs, etc.

Muitos poderiam dizer, principalmente os defensores mais ferrenhos, que devem sempre fazer as coisas simples.  Minha resposta : no final, caso faça algo descendente, é bem possível que “esbarre” num padrão.

Outra coisa que não concordo é a questão de não se discutir arquitetura… Para um projeto pequeno, você pode se dar ao luxo de não pensar nisso, pelo menos, num primeiro momento, mas para projetos grandes, tem que pensar nos componentes pois isso influirá diretamente na forma que time irá implementar as coisas. Novamente reforço que, quando sugiro usar padrões, não é pegar o livro e fazer tudo que está dizendo ali. Nada nos impede de adaptar a sugestão para nossa realidade.

Rebeldia  e revolução a parte, sempre vou dizer que o melhor caminha continua sendo o do meio. Ficar com o melhor de todos os mundos é o paraíso a ser desejado.