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.

O termo foi cunhado em 1995 por Andrew Koenig, 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 Anti Patterns, 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 organizacionais

• 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 (ou Design por comitê): o resultado de ter vários contribuintes para o projeto, mas nenhuma visão unificada;
• Agravamento de compromisso (ou Escalação de Compromisso): falhar em revogar uma decisão quando a mesma se revela 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 ou subordinação dividida 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 componente externo;
• Stovepipe ou Silos: uma estrutura que suporta principalmente o fluxo vertical (de cima para baixo) de informação, mas inibe a comunicação organizacional;
• Vendedor bloqueado: tornar um sistema excessivamente dependente de um componente externo.

Anti-patterns de Gerenciamento de Projetos

• Marcha para a morte: todos sabem que o projeto caminha para um desastre, exceto o presidente da empresa, o CEO. Porém, a verdade permanece ocultada, escondida, e a sobrevida do projeto é mantida artificialmente até que o “Dia D” chega. Definição alternativa de marcha para a morte: funcionários sofrem pressões para trabalharem dias, noites e fins de semana em um projeto com prazo irracional;
• Pensamento em grupo (ou Groupthink): durante o groupthink, membros do grupo evitam mencionar pontos de vista que estejam fora da zona de conforto do pensamento consensual.
  Fumaça e espelhos: demonstrar funções não implementadas como se já tivessem sido implementadas;
• Software bloat (inchaço do software): permitir versões sucessivas de um sistema a fim de demandar cada vez mais recursos;
• Modelo em cascata: Um velho método de desenvolvimento que lida inadequadamente com mudanças inesperadas.

Anti-padrão de análise

• 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

• 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

• 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 sub-rotina;
• Â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 consequê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

• 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 favorit é aplicável universalmente;
• Fator de improbabilidade: assumir que é improvável que um erro conhecido ocorra;
• Otimização prematura: preocupar cedo com eficiência, sacrificando um bom desenho, manutenibilidade 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.

Fonte: Wikipedia