Antipadrões de projeto de software

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa

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.

Anti-padrões conhecidos[editar | editar código-fonte]

Anti-padrões organizacionais[editar | editar código-fonte]

Anti-padrões de gerência de projeto[editar | editar código-fonte]

  • 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 | editar código-fonte]

  • 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 | editar código-fonte]

  • 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 | editar código-fonte]

  • 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 quando 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 | editar código-fonte]

Referências[editar | editar código-fonte]

  1. 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'."
  2. 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."
  3. Koenig, Andrew. (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8 (1): 46–48 pp..; 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."