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 projeto 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
Anti-padrões organizacionais
- Paralisia de análise: Dedicar esforço desproporcional à fase de análise do projeto
- Barraca de bicicleta: Dedicar grande esforço a questões triviais.
- ''Bleeding Edge'': Usar tecnologias de ponta instáveis e/ou não testadas, sendo causa de transbordamento do orçamento, baixo desempenho e/ou atraso na entrega
- Apatia dos envolvidos: O fenômeno no qual as pessoas ficam menos propensas a oferecer ajuda a outra pessoa quando outras pessoas estão presentes
- 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
- Pensar em grupo: Um estado coletivo onde membros de um grupo começam a (comumente sem saber) pensar semelhantemente e passam a rejeitar pontos de vista diferentes
- Gerência por objetivos: Gestão por números, focando exclusivamente em critério de gerência quantitativo, quando estes não são essenciais ou custam muito para alcançar
- ''Microgerência'': Ineficácia da observação e supervisão excessivas, ou outros excessos do envolvimento da gerência na prática
- Risco moral: Isolar alguém das consequências da sua decisão
- Gerência cogumelo: Manter funcionários desinformados e mal-informados
- Princípio de Peter: Continuamente promover empregados bem sucedidos até o nível em que eles são incompetentes, onde ficam indefinidamente
- Gerência gaivota: Gerência onde os gerentes só interagem com os empregados quando um problema aparece, ocasião na qual eles "pousam, fazem muito barulho, culpam todos, não resolvem o problema e então voltam a voar"
- Funil ou silo: Uma estrutura organizacional de times isolados ou semi-isolados, nos quais muita comunicação sobe e desce na hierarquia, ao invés de ir diretamente aos outros times da organização
- Distribuição de papéis: Bloqueio de empregados de sucesso em demasiadamente seguros, estreitamente definidos, previsíveis papéis baseados em seus sucessos passados ao invés de levar em conta seus potenciais
- Aprisionamento tecnológico: Fazer um sistema excessivamente dependente de um componente externo
- 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
Anti-padrões de gerência de projeto
- 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
- 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 requeridas 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 favorita é 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
