Antipadrão – 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 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

Referências

↑ Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. 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 (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. 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 (março–abril de 1995). «Patterns and Antipatterns». Journal of Object-Oriented Programming. 8 (1): 46–48 ; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. 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."

[1] Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. 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 (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. 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 (março–abril de 1995). «Patterns and Antipatterns». Journal of Object-Oriented Programming. 8 (1): 46–48 ; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. 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."

[1]

[2]

[3]