.NET
- Anti-Patterns ou Anti-Padrões
Hoje eu vou falar sobre
Anti-Patterns ou Anti-Padrões.
| Obs: Estou escrevendo
Anti-Patterns/Anti-Padroes ,mas não sei se esta é a forma
correta de escrever; segundo a regra anterior deveríamos escrever
antipatterns (só se usuaria o hifem antes do h, r e s e vogal
í) |
O termo Anti-Patterns foi criado em
1995 por Andrew Koenig, inspirado no livro da Gang of Four,
que desenvolveram o conceito de padrão de projeto.
Um anti-pattern ou anti-padrão,
como o próprio significado do termo sugere , significa algo contrário
ao padrão. Seria isso mesmo ???
Em engenharia de software, um
anti-padrão é uma solução semelhante a um padrão de projeto
(Design Pattern) só que sua aplicação produz conseqüências
negativas.
Assim um anti-padrão é uma
solução pois resolve um problema só que de uma forma
ineficiente.
Quem nunca viu ou ouviu falar na
famosa 'gambiarra' ? Pois ela é o exemplo prático de
um anti-padrão: resolve o problema mas é ineficiente e com
certeza vai causar problemas a curto, médio e a longo prazo.
Para relaxar um pouco...
A Programação Orientada a Gambiarras (POG ou
WOP – Workaround-oriented programming) é um paradigma da programa de
sistemas de software que integra-se perfeitamente a qualquer grande
Paradigma de programação atual.
Por definição, Gambiarra é aquilo que é de difícil
concepção, de inesperada execução para tornar fácil o uso de algo que sequer
deveria existir.
A Programação Orientada a Gambiarras foi uma
evolução natural do uso do Programa bacalhau, também conhecido como
ATND - "Artifício Técnico Não Documentado"
Para que um programador possa exercer a Programação
Orientada a Gambiarras, são necessários alguns fatores específicos,
facilmente encontrados em ambiente de desenvolvimento:
- Sistemas originalmente mal projetados
- clientes chatos
- Usuários chatos
- Falta de vontade
- Falta de tempo
- Gente que pensa que é DBA (normalmente
são pessoas chatas, gordas, feias, sem certificação nenhuma e que fizeram
um curso de SQL Básico)
- Arquiteto de software achando que é o
máximo (normalmente pessoas altas, loiras, chatas, arrogantes e metidos a
sabe-tudo)
- Término do estoque de café/chá
- Aproximação do final da tarde
- Véspera de feriado/fim-de-semana
Seria cômico senão fosse trágico.
Fonte:
http://tiny.cc/10p4c |
Os anti-padrões não são uma
característica da engenharia de software (é claro) estão em todas as
áreas; para ilustrar isso veja uma relação de anti-padrões
sociais e de software:
| Anti-Padrões
Sociais |
Anti-Padrões de
Software |
| Criminoso |
Código Espagueti |
| Terrorista |
Classes SuperPoderosas |
| Pervertido |
Botão Mágico |
| Traficante |
Anemic Model Model |
| Herético |
Grande bola de lama |
O problema com os anti-padrões e
que eles muitas vezes estão documentados e são usados como se
fossem a solução para determinados tipos de problemas mas que
acabam acarretando problemas maiores.
Seriam os anti-padrões um mal
hábito ou uma má prática ?
Em essência não. Os anti-padrões
são mais do que isso.
Vejamos algumas características dos
anti-padrões:
- Os Anti-Padrões são soluções
negativas que apresentam mais problemas do que se propõem a
resolver;
- Os Anti-Padrões são uma extensão natural dos Padrões de
Projeto; (O maior perigo é quando a mentira se parece com a
verdade.)
- Os Anti-Padrões são a ponte entre a lacuna existente entre os
conceitos de arquitetura e a implementação do mundo real;
- Os Anti-Padrões, apresentam uma solução comum que refaz o
sistema de modo a maximizar os benefícios e minimizar as
conseqüências (aspectos negativos);
- Os Anti-Padrões identificam abordagens técnicas equivocadas e
práticas de desenvolvimento erradas que levam ao desenvolvimento
de software de má qualidade e ao fracasso de projetos de
software;
Compreender e conhecer os Anti-Padrões permite-nos
evitá-los pois são uma armadilha que levam a situações desastrosas.
Dessa forma um Anti-Padrão é um
Padrão de Projeto que pode (e infelizmente é) ser
usado para resolver um problema mas é ineficiente e apresenta
resultados negativos.
Mas o que faz com que , mesmo
apresentando os problemas conhecidos, os anti-padrões continuem
a serem usados ?
Vejamos as principais causas da
utilização dos anti-padrões :
- Orgulho ( É só
fazer do jeito que eu to falando que entregamos na data correta)
- Preguiça ( Fazer essa
refatoração é muito
complicado então deixa assim mesmo que vai dar certo)
- Pressa ( Não precisa testar
tudo não, temos que entregar isso amanhã...)
- Ignorância (O
que essa parte desse código faz mesmo
?)
- Desleixo ( Não quero nem
saber, se compilou é porque funciona)
- Avareza ( Pra que gastar
com mão de obra especializada, manda o estagiário fazer isso., o cara é fera)
- Irresponsabilidade (Se
ninguém reclamou é porque está funcionando.)
Na engenharia de Software os
Anti-Padrões são divididos em três classes:(fonte:
http://www.ime.usp.br/~kon/MAC5715/aulas/Aula6.html)
- Anti-Padrões de
Desenvolvimento - relacionados à programação;
- The Blob
- referência a filme B com monstro extra-terrestre de geléia que come tudo
a sua volta e cresce cada vez que come algo. O alienígena chega do espaço
sideral na forma de uma gotinha gelatinosa e vai crescendo até se tornar uma
ameaça para o planeta inteiro :
- ocorre freqüentemente com programadores novos em OO que vem de
linguagens procedurais e que concentram a maior parte do sistema em uma classe
central que passa a ter dezenas de métodos e atributos. Outras classes
pequenas orbitam o Blob e servem apenas para guardar pequenas estruturas de
dados.
- Causas Típicas:
- falta de arquitetura OO;
- falta de arquitetura, o sistema é uma grande massa disforme;
- preguiça: ao estender o sistema, ao invés de adicionar novas classes,
programadores incham as classes existentes;
- Solução refatorada: remova responsabilidades do Blob e as transfira para
as classes que o orbitam. A longo prazo, o objetivo é um desenho OO de
melhor qualidade onde os objetos interagem entre si e não numa arquitetura
de estrela centrada no Blob;
- Exceção conhecida: um Blob é aceitável quando estamos encapsulando um
sistema legado dentro de uma grande classe. Não queremos modificar o sistema
legado, queremos apenas acessá-lo a partir do nosso sistema OO;
- Lava Flow
- Historinha-Evidência:
- "AAHHH, isso? Bem, o Marcelo e o Edson escreveram esta rotina
quando o João (que saiu da empresa no mês passado) estava tentando
resolver o problema das funções de entrada e saída implementadas pela
Irene (que agora trabalha no departamento de vendas). Eu acho que esse
código não é mais utilizado, mas não tenho certeza. O Marcelo não escreveu
nenhuma documentação e nós não temos testes automatizados, então acho
melhor não mexer nisso pois pode quebrar alguma coisa. Afinal, está
funcionando do jeito que está, não está? Então é melhor não mexer."
- Forma geral:
- Fluxo de Lava é encontrado muitas vezes em sistemas que começaram como
experimentação mas que acabaram em produção.
- É caracterizado por ondas de código disforme de versões anteriores que
deslizam para as versões novas sem termos muito controle sobre elas.
- Partes da lava podem se solidificar na forma de grandes rochas e serem
carregadas pelo fluxo de lava derretida. Como grandes partes de código
antigo que são incorporados ao sistema sem sabermos exatamente o que ele
faz e se ele é realmente necessário.
- Sintomas e Conseqüências:
- alta freqüência de variáveis e fragmentos de código não justificados
- funções aparentemente importantes completamente não-documentadas que
na verdade não se relacionam claramente à arquitetura do sistema
- Grandes blocos de código entre comentários sem justificativa
- Muitos comentários do tipo /* Substituir isso */ /* Em construção */
- Interfaces nos arquivos de cabeçalhos que não são usadas e que não
podem ser explicadas pelos programadores atuais
- Se a lava se solidifica, se torna impossível a compreensão e
documentação do código existente e a falta de conhecimento da arquitetura
se torna tão grande que fica praticamente impossível implementar melhorias
no sistema.
- Refactored Solution:
- Só há uma maneira de evitar: garantir que a todo momento se tenha uma
clara noção da arquitetura do sistema e que todo o código seja compatível
com esta arquitetura.
- Quando o fluxo de lava já existe, a cura em geral é muito dolorosa:
- especialistas devem conduzir uma mineração do código cuidadosa
(investigar o que há lá e tentar entender a arquitetura) e daí remover
as partes inúteis e refatorar a arquitetura.
- às vezes, implementar o item anterior é tão difícil que a solução é
jogar o código fora e começar de novo com uma arquitetura clara.
- Poltergeists
- um poltergeist é um fantasma que aparece de repente no meio da noite,
esbarra na nossa frente e desaparece misteriosamente.
- é comum com programadores muito especialistas nas especificidades de uma
determinada linguagem e que usam esse conhecimento para o mal.
- por exemplo, programadores de LISP ou C que usam efeitos colaterais da
linguagem para fazer coisas importantes no sistema.
- poltergeists podem se manifestar na forma de classes estranhas dentro do
sistema que não fazem parte da arquitetura mas que são usadas de vez em
quando para realizar alguma tarefa-chave que ficou faltando.
- uma forma muito comum entre "maus-bons programadores" são trechos de
código ultra eficientes e geniais que ninguém entende a não ser o próprio
programador.
- Spaghetti Code
- Historinha-Evidência: "Argh, que meleca! Você sabe que em Java você pode
ter mais do que uma classe por aplicação, né ? Do jeito que está é mais
fácil re-escrever tudo do que tentar consertar".
- Forma Geral: aparece em sistemas que tem muito pouca estrutura. Em
geral, temos poucas classes com poucos métodos, e cada método é enorme.
- Exceção aceitável: quando se está testando uma arquitetura e se
implementa uma das componentes do sistema usando código espagueti. A
interface da componente tem que ser muito bem feita para não contaminar o
resto do sistema. Uma vez terminado o teste, deve-se jogar fora o
código espagueti e reimplementá-lo decentemente.
- Solução refatorada: utilizar técnicas de refatoramento de código para
redistribuir o código de forma mais OO, criando novas classes e métodos.
- Input Kludge
- software que falha com entradas triviais;
- Historinha: "O programador disse que o programa estava pronto e que
funcionava perfeitamente e que eu poderia testar. Sentei na frente do
computador, apertei <enter> e o sistema deu Falha de Segmentação ".
- Cut-and Paste Programming
- Historinhas:
- "Ei, eu pensei que você já tinha consertado esse erro, por que está
acontecendo de novo?"
- "Puxa, vocês são bons mesmo, 400.000 linhas de código novo em duas
semanas? Que progresso, parabéns!"
- Programação baseada em copiar e colar é a pior forma de re-utilização de
código. Herança (re-utilização caixa branca) é melhor pois evita a repetição
do código. Componentes tipo caixa preta é ainda melhor pois evita repetição
e incentiva o desacoplamento.
- Soluções relacionadas: em geral, código espagueti está cheio de
cut-and-paste programming. Identificar repetições e criar um único
método para elas.
- Mushroom Management
- Em algumas empresas se diz que os desenvolvedores não devem ter contato
com usuários finais, que a intermediação deve ser feita por Analistas de
Requisitos especializados nisso.
- Historinha: "Mantenha os seus desenvolvedores no escuro e alimente-os
com fertilizante".
- Normalmente, os desenvolvedores acabam construindo o sistema errado.
- Anti-Padrões Arquiteturais -
relacionados à estrutura dos sistemas;
- Vendor Lock-In
- Construção de sistemas que são altamente dependentes de interfaces
proprietárias.
- Solução:
- use interfaces padrão (Ex: CORBA, assim você não depende de um só
fabricante)
- crie uma camada de isolamento arquitetural entre o seu sistema e a
plataforma de um fabricante específico
- Design by Committee (projeto de comitê)
- Muita gente trabalhando junto para projetar a mesma arquitetura sem um
método bem organizado;
- Conseqüência: arquitetura excessivamente complexa para atender a
todas as diferentes opiniões e pontos de vista;
- Solução:
- limite grupo a não mais do que 10 pessoas.
- use processos bem definidos e planejados (Ex: processo do OMG para
definição de CORBA) (será?)
- Swiss Army Knife
- É uma classe cuja interface é grande demais. O projetista tenta
antecipar na interface todos os possíveis usos da classe no futuro.
- Reinvent the Wheel
- Historinha: "Este problema é único no mundo. Antes de continuar
implementando os requisitos básicos, vamos implementar uma biblioteca nova
para cuidar desta questão".
- Anti-Padrões Gerenciais -
relacionados aos processos e métodos de desenvolvimento
nas empresas e grupos de desenvolvimento de software;
- Analysis Paralysis
- Analistas buscam o entendimento perfeito e completo do problema. Passam
meses estudando as questões relacionadas ao problema ao invés de colocar a
mão na massa e começar a projetar e implementar o sistema.
- Solução: desenvolvimento incremental.
- Death by Planning
- Excesso no planejamento do que se vai fazer. Cronogramas excessivamente
complexos que se mostram impraticáveis na vida real.
- Intellectual Violence
- Utilização prepotente de um conhecimento sobre uma determinada teoria,
tecnologia ou jargão específico para intimidar outras pessoas numa reunião.
- Smoke and Mirrors
- Também conhecido como Vaporware
- Gerentes pedem para programadores criarem GUIs com a casca de um sistema
ainda não desenvolvido para mostrar a potenciais clientes o que poderia ser
feito;
- Programadores explicam para gerentes e vendedores que nada está feito na
realidade e que demoraria meses ou anos para fazer de verdade;
- Vendedores ignoram a advertência dos programadores e VENDEM o sistema
antes de que ele exista;
Vejamos a seguir uma análise resumida de um anti-padrão muito conhecido e usado pelos
desenvolvedores de software:
O anti-padrão código Espaguete (Spaghetti
Code)
Definição:
Qualifica-se de código espaguete
um programa de computador que não segue as regras da
programação e abusa de desvios, condicionais ou não, o que
torna a leitura do mesmo por seres humanos bem difícil. O sistema é difícil de
entender, de manter e de testar.
Ele é conseqüência do estilo de
adotados por muitos desenvolvedores: sentar na frente do
computador e começar a programar.
Sintomas do padrão:
- Código confuso e mal
estruturador;
- Usos de controles
Causas Principais : Ignorância, Preguiça, Displicência;
Tipo da solução : Refatoração do Software;
Nome da solução : Software Refactoring, Code Cleanup;
Escala mais freqüente : Aplicação;
Você alguma vez se enquadrou em um dos
anti-padrões aqui citados ? (seja sincero...)
Eu sei é apenas anti-padrões mas eu
gosto...
Jesus disse-lhes: A minha comida é fazer
a vontade daquele que em enviou, e realizar a sua obra. (João 4:34)
Referências:
José Carlos Macoratti