Antipadrões de projeto de software
Origem: Wikipédia, a enciclopédia livre.
Em Engenharia de software, um anti-padrão é um padrão de projeto de software que pode ser comumente usado mas é ineficiente e/ou contra-produtivo em prática.1 2
O termo foi cunhado em 1995 por Andrew Koenig, 3 inspirado pelo livro do Gang of Four Design Patterns, que desenvolveu o conceito de padrão de desenho de software. O termo foi largamente popularizado três anos depois pelo livro AntiPatterns, que estendeu o uso do termo além do campo de desenho de software para interações pessoais em geral. De acordo com os autores do último, deve haver ao menos dois elementos chave para formalmente distinguir um anti-padrão real de um mau hábito, má prática ou má ideia:
- Algum padrão repetido de ação, processo ou estrutura que inicialmente parecia benéfico, mas, como consequência produz mais malefícios do que benefícios, e
- Uma refatoração de código existe que é claramente documentada, demonstrada na prática e reproduzível.
Várias ideias de anti-padrões são pouco mais que erros, discussões, problemas insolúveis, ou más práticas a serem evitadas, se possível. Às vezes chamados de armadilhas ou padrões escuros, esse uso informal do termo veio a referir classes de más soluções para problemas frequentemente reinventadas. Assim, vários candidatos a anti-padrões não seriam formalmente considerados anti-padrões.
Pela descrição formal de erros repetidos, é possível reconhecer as forças que levam à sua repetição e aprender como outros refatoraram códigos saindo desses padrões quebrados.
Índice |
Anti-padrões conhecidos [editar]
Anti-padrões organizacionais [editar]
- Paralisia de análise: Dedicar esforço desproporcional à fase de análise do projeto
- Vaca do dinheiro: Um produto legado que às vezes leva à complacência sobre novos produtos
- Projeto por submissão: O resultado de ter vários contribuintes para o projeto, mas nenhuma visão unificada
- Agravamento de compromisso: Falhar em revogar uma decisão quando provada errada
- Gerência por perkele: Estilo autoritário de gerência sem tolerância à divergências
- Departamentalização matricial: Estrutura organizacional desfocada que resulta em lealdades divididas e falta de direção
- Risco moral: Isolar alguém das consequências da sua decisão
- Gerência cogumelo: Manter funcionários desinformados e mal-informados
- Aprisionamento tecnológico: Fazer um sistema excessivamente dependente de um componenete externo
Anti-padrões de gerência de projeto [editar]
- Marcha da morte: Todos sabem que o software será um desastre - exceto o CEO - então a verdade é escondida
- Pensamento de Grupo: Durante pensamentos de grupo, membros evitam demonstrar pontos de vista fora da zona de conforto
- Fumaça e espelhos: Demonstrar funções não implementadas como se já tivessem sido implementadas
- Modelo em cascata: Um velho método de desenvolvimento que lida inadequadamente com mudanças inesperadas
Anti-padrão de análise [editar]
- Apatia do espectador: Quando uma decisão de análise é errada, mas quem percebe não faz nada pois afeta um número maior de pessoas
Anti-padrões gerais de design [editar]
- Inversão de abstração: Não expor funcionalidades implementadas requiridas pelos usuários, então elas são re-implementadas em mais alto nível
- Grande bola de lama: Um sistema sem uma estrutura reconhecível
- Gold plating: Continuar a trabalhar em uma tarefa ou projeto passando do ponto em que esforço extra adiciona valor
- Gambiarra de entrada: Falha ao especificar e implementar o manuseio de uma possível entrada inválida
- Inflação de interface: Fazer uma interface tão poderosa que ela é extremamente difícil de implementar
- Condição de corrida: Falhar ao ver as consequências de uma ordem alterada de eventos
- Sistema chaminé: Um sistema montado difícil de ser mantido pelos componentes mal-relacionados
Anti-padrões de programação [editar]
- Complexidade acidental: Introdução de complexidade desnecessária em uma solução
- Ação à distância: Interação inesperada entre partes distantes de um sistema
- Fé cega: Falta de checar (a) a correção de um bug ou (b) o resultado de uma subrotina
- Âncora do barco: Manter uma parte de um sistema que não tem mais uso
- Espera ativa: Consumir CPU enquanto espera por algo acontecer, normalmente checando várias vezes ao invés de enviar mensagem
- Culto de programação: Usar padrões sem saber o motivo
- Programando por exceção: Adicionar código novo para lidar com cada caso especial quande esse é reconhecido
- Fluxo de lava: Manter código indesejável (redundante ou de baixa qualidade) porque removê-lo é caro ou tem conseguências imprevisíveis
- Números mágicos: Incluir números inexplicados em algoritmos
- Strings mágicas: Incluir literais no código para comparações inexplicadas
- Don't repeat yourself': Escrever código que contém padrões repetitivos, a serem evitados com o princípio da abstração
- Código espaguete: Programas que têm a estrutura pouco compreensível, especialmente por mal uso das estruturas de código
Anti-padrões metodológicos [editar]
- Programação por copiar/colar: Copiar (e modificar) código existente ao invés de criar soluções genéricas
- Martelo de ouro: Assumir que uma solução favoritt é aplicável universalmente
- Fator de improbabilidade: Assumir que é improvável que um erro conhecido ocorra
- Não inventado aqui Tendência em reinventar a roda (Falhando em adotar uma solução adequada e existente)
- Otimização prematura: Preocupar cedo com eficiência, sacrificando um bom desenho, manutenabilidade e às vezes até eficiência
- Reinventar a roda: Falhar em adotar uma solução adequada e existente
- Reinventar a roda quadrada: Falhar em adotar uma solução existente e no lugar adotar uma customizada que é bem pior
Referências [editar]
- ↑ Budgen, D.. Software design. Harlow, Eng.: Addison-Wesley, 2003. p. 225. ISBN 0-201-72219-4 "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
- ↑ Scott W. Ambler. Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press, 1998. p. 4. ISBN 0-521-64568-9 "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
- ↑ Koenig, Andrew. (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48.; was later re-printed in the: Rising, Linda. The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press, 1998. p. 387. ISBN 0-521-64818-1 "Anti-pattern is just like pattern, except that instead of solution it gives something thats looks superficially like a solution, but isn't one."
