Já faz algum tempo que prometo este post: padrões enganam. Nada contra padrões em si o que seria uma tolice visto ser o próprio processo de aprendizado e inteligência baseado em sua presença mas sim o potencial imbecilizante que estes possuem quando mal aplicados. No desenvolvimento de software acredito que podem inclusive ser fatais quando isto ocorre.
Meu primeiro contato com os padrões de projeto: admiração e medo
Já mencionei esta minha experiência aqui no blog quando contei como a orientação a objetos entrou em minha vida. Meu primeiro contato com os padrões de projeto foi composto por dois momentos: admiração e pânico.
A admiração veio quando percebi que outras pessoas enfrentavam os mesmos problemas que nós e apresentavam soluções bem interessantes para aquelas questões. Mais do que isto: os padrões me forneciam vocabulário que passava a fazer parte do dia a dia da nossa equipe. Palavras como factory, proxy, bridge, adapter e outras nos ajudavam a transmitir idéias de uma forma mais rápida e direta.
(surgia um jogo legal: quando usávamos estas novas palavras em nossas conversas era como se estivéssemos treinando aquilo que aprendíamos nos livros e artigos que nos encontravam)
O pânico veio quando o padrão se tornou lei e a argumentação desapareceu. De repente nossas soluções só eram válidas se caissem em um dos padrões que haviamos aprendido a adorar. O terrível, fraco e covarde argumento da autoridade se impôs: quem eramos nós pra pensar algo diferente do que Erich Gama, Richard Helm, Ralph Johnson e John Vissides e de melhor qualidade?
A ingênua pergunta “por que você não usou um factory?” tinha um novo tom: não era mais um questionamento a respeito de qual caminho tomar mas sim uma crítica por não ter seguido a direção indicada por estes seres superiores. Frases como “iremos usar um factory, com a ajuda de um builder para montar nosso proxy que é um adapter para o command” proliferavam, e percebíamos que os padrões haviam se tornado componentes e não mais propostas, visões diferentes, idéias. Nós uníamos estes padrões apenas e a ilusão de que um sistema sairia dali sempre vinha. Funcionou uma vez ou duas: então era massa, certo?
Um rebelde na ditadura dos padrões?
Era absurda a situação: não poder questionar um padrão ou mesmo seu uso de repente me fez perceber que estava diante de uma ditadura dos padrões. Quanto mais os questionava percebia em meus colegas que minha imagem passava a ser a de um rebelde arrogante.
Será que o padrão era realmente aplicável a qualquer situação ou na realidade este não estaria ocultando nossos medos e inseguranças?
Foi quando caiu a ficha: os padrões de projeto não eram mais ferramentas mas sim máscaras usadas para ocultar nossa insegurança. Foi quando conheci os dois melhores amigos do padrão mal aplicado: Sr. Medíocre e Sra Medo.
Não há nada de errado no medo ou mediocridade em si. Convenhamos: têm seu lugar e é um verdadeiro latifúndio. Inclusive possuem seus próprios habitats naturais, como por exemplo as terras do prazo apertado e a ilha do solo duvidoso aonde seus habitantes nunca sabem no que pisam.
(Agir com cautela é natural: há inclusive um diálogo platônico muito interessante chamado Laques aonde a principal questão é o limite entre a coragem e a tolice.)
Os desastrosos padrões ditatoriais na arquitetura
Conforme fui amadurecendo minha visão foi do micro para o macro: entrou a arquitetura e novamente vi o mesmo probelma se manifestando na figura do arquiteto ditador de padrões. Acho que é fruto da leitura ao pé da letra daqueles textos nos quais liga-se diretamente a figura do arquiteto com a definição dos padrões do sistema, ou se bobear é mero egocentrismo mesmo.
(aliás, já repararam que no egocêntrico há muito do inseguro?)
Era imposta uma solução arquitetural e esta devia ser aplicada a todas as situações. O problema é que sempre surgiam aqueles casos que furavam o padrão. Era quando me perguntava: trocamos/aprimoramos o padrão ou passamos a aceitar a diversidade de soluções que precisamos aplicar? Normalmente quando a resposta era um cego “siga o padrão porra!” a equipe dava voltas gigantescas para resolver problemas simples.
(mas não há como fugir da necessidade dos padrões. Por favor não entenda este texto como uma declaração de guerra aos mesmos ok?)
Neste caso o padrão só servia para mostrar a arrogância e inaptidão do arquiteto em ouvir a equipe.
Conclusões
Eu poderia escrever um artigo longo sobre o potencial imbecilizador dos padrões quando aplicados ao desenvolvimento de sistemas mas na prática eu estaria apenas escondendo um fato mais evidente: este potencial imbecilizador é na realidade a manifestação da incompetência ou imaturidade (as duas se misturam).
O grande problema na minha opinião é que o incompetente usa a imposição dos padrões como sua ferramenta para dominar o outro. Em si os padrões são e deveriam ser vistos como sugestões, idéias dos caminhos que poderíamos seguir pra resolver nossos problemas. Se você observa situações do tipo “temos de ter uma solução que abarque todos os casos”, abra o olho: eu e você sabemos bem que a realidade sempre é mais complexa que a nossa solução infantil tenta abraçar.
Antes que digam, não, não sou contra padronizações, padrões de projeto, arquitetura, etc. Sou contra a ditadura que os incompetentes criam os usando como muletas.
Insegurança, falta de tempo ou paciência para estudar melhor o problema, arrogância. Isso tudo pode levar um arquiteto a fugir de suas responsabilidades e acabar levando receitas de bolo para um churrasco. Um bom arquiteto não pode fugir da responsabilidade de conciliar as necessidades da equipe e do projeto, e essas responsabilidades são grandes e pesadas.
Por outro lado, percebo algumas comunidades de desenvolvedores assustadoramente apegadas a padrões. A impressão que tenho é essa ai mesmo que você passou, que pra fazer um “alô mundo” deve-se seguir pelo menos 12 dos 23 padrões do GoF, se não tá errado. E muitos novos desenvolvedores parecem já entrar no mercado com a mente travada no uso de padrões, quando o mais importante não são os padrões, mas os princípios. Uso padrões quando preciso e se preciso, e não me apego ao formato deles se não forem ideais pro que preciso. Meu compromisso é com a solução que vou apresentar, não com uma receita de bolo.
Coincidentemente acabei de escrever sobre outro problema relacionado, o problema do arquiteto astronauta: http://www.rafaelromao.com/
Opa, acabei de ler. Massa!
É: cara, é sempre a mesma história. Insegurança e imaturidade (as duas andam juntas parece) se manifestando.
ARQUITETO, essa palavra por sí só me faz arrepiar, ela deveria ser banida do vacabulário de TI, agrega muito em termos organizacionais, e até de salário, mas é só isso. O problema, concordo não é o padrão, mas é uma tendência recorrente onde este deve ser seguido a qualquer custo. Não vejo isso como medo e nem medíocre, afinal se isto é válido então como o indivíduo agrega algo a organização/projeto? Na minha visão é a zona de conforto. Após muito tempo seguindo métricas e doutrinas é muito comum que nos encontremos neste tipo de situação, a da comodidade. Se isto funcionou durante anos por que levanterei a minha voz contra? Não é um problema de quem pensa, mas sim de quem não quer pensar. Software por vezes acaba sendo da mesma forma. E este sim é um padrão que vem sendo seguido por muitos desenvolvedores, e o que me preocupa é que ele vem sendo passado para novas gerações sem nenhum controle epdemiológico. “Parem as máquinas!”
A ditadura de padrões realmente é terrível.
Acho que parte disso vem do termo PADRÃO e a conotação que isso tem em português.
Por isso, tenho o costume de chama-los de MOLDES DE MODELAGEM:
http://alexandreaquiles.com.br/2014/02/10/moldes-de-modelagem/