Quais são os piores anti-padrões que você encontrou em sua carreira como programador?

Estou envolvido principalmente com java, embora provavelmente seja independente da linguagem.

Eu acho que o pior é o que eu chamo de principal anti-padrão . Significa programa composto por uma classe extremamente grande (às vezes acompanhada de um par de turmas pequenas) que contém toda a lógica. Normalmente, com um grande loop no qual toda a lógica de negócios está contida, às vezes tendo dezenas de milhares de linhas de código.

Código comentado. Blocos, talvez centenas de linhas. Sendo a teoria, ei, é comentado, não faz mal algum e talvez precisemos dela no futuro.

Vou acertar outro óbvio com "copy-pasta". Copiar código quase idêntico ao que você deseja e alterar algumas coisas (em vez de extrair para um método).

Isso é especialmente predominante em alguns códigos de teste funcionais e de API do final dos anos 90: literalmente centenas (ou até milhares) de casos de teste quase idênticos que poderiam ter sido divididos em algumas funções com três ou quatro parâmetros - ou, melhor ainda , algo orientado a dados. Meu primeiro emprego fora da faculdade foi, literalmente, oito meses reescrevendo e refatorando milhares de linhas de massas de cópia que usavam métodos obsoletos. Quando terminei, os arquivos de teste tinham menos de um décimo do tamanho original e eram muito mais fáceis de manter (e legíveis!).

Penso que posso escrever muito sobre o Pattern Mania e soluções que poderiam ser resolvidas com muito menos esforço, mas prefiro apontar para um ótimo artigo que li recentemente com um exemplo fantástico de como uma solução simples pode ser complicada demais .

Como (não) escrever o fatorial em Java, colocamos uma fábrica no seu algoritmo

Martelo de Ouro

"Eu tenho um martelo e todo o resto é um prego."

Regiões

Em C #, você pode definir uma região de código que pode ser recolhida no IDE, ocultando-a, a menos que você queira lidar com esse código. Eu participei de um projeto em que as regiões abrangem centenas de linhas (gostaria de estar exagerando) e havia várias regiões em uma função de mil linhas (novamente, eu gostaria de estar brincando).

No lado positivo, o desenvolvedor que criou a região fez um trabalho muito bom na identificação de funções específicas dentro de uma região. Tanto que eu era capaz de fazer um método de extração na região e seguir em frente.

As regiões incentivam os desenvolvedores a "esconder" sua porcaria à vista.

Para mim, o pior padrão é Copiar / Colar .

Métodos que não sobrecarregam:

// Do something
public int doSomething(Data d);

// Do same thing, but with some other data
public int doSomething2(SomeOtherData d);

Mostra claramente que o programador não entendeu a sobrecarga.

Sequências de comutação de loop

http://en.wikipedia.org/wiki/Loop-switch_sequence

Eles me irritam sem fim e mostram realmente como o desenvolvedor era inexperiente

Codificação flexível , ou seja, quando os programadores se esforçam para evitar a codificação embutida e acabam do outro lado da escala - dependências "codificadas".

Mantenha o estado no cliente.

Uma vez trabalhado com um aplicativo da web em que todo o estado foi mantido no navegador. (Para garantir a escalabilidade sem problemas, todas as exceções foram ignoradas).

Checkins maciços

Odeio quando vejo que um desenvolvedor não faz o check-in há mais de uma semana. Isso significa que ele está preso e não procurou ajuda, ou está reunindo vários recursos em um grande check-in. (Eu deixei de lado o pior cenário, ele simplesmente não está fazendo nada. Isso é fácil de resolver ... duas palavras parecem que você foi contratado.)

Ao fazer um grande check-in, você perde muitos benefícios do SCM, como poder vincular um conjunto de alterações a um recurso específico. Além disso, é provável que você tenha muita fusão a fazer e isso não é necessariamente fácil de acertar.

Atualmente, estou trabalhando com um pedaço de código legado e adoro a maneira como o codificador anterior obtém o primeiro elemento de uma lista:

String result;
for(int i = 0; i < someList.size(); i++) {
    result = someList.get(i);
    break;
}

Mas o pior que vi neste código é definir páginas JSPs em linha de classes, escrever todo o HTML, CSS e Javascript usando scriptlet e out.println :-(

Um dos piores anti-padrões comportamentais que eu vi foi uma loja que só permitia que o código fosse verificado no controle de versão depois que ele estava em produção. Juntamente com checkouts exclusivos no VSS, isso levou a um processo complicado de desfazer checkouts, se um defeito de produção precisasse ser corrigido antes do próximo lançamento, muito menos mais uma pessoa precisando alterar um determinado arquivo para o próximo lançamento.

O fato de ser uma política departamental tornou ainda pior do que o caso de um único desenvolvedor se comportando dessa maneira.

Bloqueando um literal String

synchronized("one") { /* block one A*/ }

synchronized("one") { /* block one B*/ }

Nomes de classe muito longos. (no JRE)

com.sun.java.swing.plaf.nimbus.
InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState

Estrutura de herança insuficiente

com.sun.corba.se.internal.Interceptors.PIORB extends
com.sun.corba.se.internal.POA.POAORB extends
com.sun.corba.se.internal.iiop.ORB extends
com.sun.corba.se.impl.orb.ORBImpl extends
com.sun.corba.se.spi.orb.ORB extends
com.sun.corba.se.org.omg.CORBA.ORB extends 
org.omg.CORBA_2_3.ORB extends
org.omg.CORBA.ORB

Uma exceção que não é.

public interface FlavorException { }

Manipulação de erro inútil e enigmática

if (properties.size() > 10000)
   System.exit(0);

Criação desnecessária de objetos

Class clazz = new Integer(0).getClass();
int num = new Integer(text).intValue();

Lançando uma exceção para outros fins

try {
    Integer i = null;
    Integer j = i.intValue();
} catch (NullPointerException e) {
    System.out.println("Entering "+e.getStackTrace()[0]);
}

Usando objetos de instância para métodos estáticos.

Thread.currentThread().sleep(100);

Sincronizando em um campo não final

synchronized(list) {
   list = new ArrayList();
}

Cópia inútil de uma String constante

String s = new String("Hello world");

Chamada inútil para String.toString ()

String s = "Hello";
String t = s.toString() + " World";

Chama System.gc () para liberar memória

Definir variável local como null para liberar alguma memória

    // list is out of scope anyway.
    list = null;
}

Usando ++ i em vez de i ++ por razões de desempenho (ou qualquer outra micro-micro-otimização)

Código polvilhado com:

// TODO: 

ou

// TODO: implement feature 

sem informações adicionais.

Iterador para manequins:

Iterator iCollection = collection.iterator();
for(int i = 0 ; i < collection.size() ; i++ ){
    if(collection.get(i) == something){
       iCollection.remove();
    }
 }

Fábrica Singletono:

public class SomeObject{
   private SomeObject() {}
   public static SomeObject getInstance(){
       return new SomeObject();
   }
}

desenvolvimento orientado por if-else (também chamado de princípio de fechamento aberto - aberto para modificação próximo ao entendimento):

if (sth1){
...  
}else if(sth2){
..
}
...
..
else if(sth1000000000000){
...
}

StringPattern (também chamado StringObject):

a) sendercode
if(sth1)
   str+="#a";
if(sth2)
   str+="#b";
...
if(sth1000)
   str+="#n";

b) receiver
   regexp testing if str contains #a, #b, ... #n

Não é tanto um padrão de codificação, mas um padrão comportamental, é muito ruim: modificar algo no código (digamos que os requisitos mudaram) e depois ajustar todos os testes de unidade até que o código seja aprovado. Ajustando ou simplesmente removendo todo o código de teste do método de teste, mas deixando o método lá.

Isso está vinculado a um mais genérico, o padrão That'll Do , aqui está uma linha de código representativa para ele:

int num = new Integer( stringParam ).parseInt( stringParam );

Funciona, afinal.

Eu absolutamente desprezo a inversão da abstração ou a reinvenção de primitivas de baixo nível em cima de primitivas de alto nível. Às vezes, porém, isso é causado por designers de linguagem ruim, não por programadores ruins. Exemplos:

1. Usando uma única classe de método sem variáveis ​​de membro e uma interface correspondente (implementada em termos de tabelas de ponteiros de função), em vez de um ponteiro de função. Observe que em linguagens como Java, você pode não ter escolha.

2. Em MATLAB e R, a insistência de que tudo é um vetor / matriz e não um primitivo.

3. Enquanto estamos atacando o MATLAB, que tal o fato de ele não ter números inteiros? Portanto, quando você precisa de um número inteiro, deve usar um duplo.

4. Linguagens puramente funcionais, nas quais você precisa usar chamadas de função para escrever um loop.

Definitivamente seria copiar / colar, já vi muitos códigos ruins sendo feitos por causa disso, isso e codificação de cowboys e tudo o que deriva disso. (Classes de Deus, métodos extra grandes, algoritmos com más idéias, etc.)

E se os padrões de design forem permitidos, eu diria: Executando um projeto como um conjunto de ações de um plano, sem fazer nenhuma análise de design ou domínio.

Java multiuso -

Um java bean com muitas variáveis, usado em alguns tipos diferentes de operações. Cada operação usa algum subconjunto arbitrário das variáveis ​​do bean e ignora as outras. Algumas variáveis ​​para o estado da GUI, algumas variáveis ​​usadas para passar entre componentes, algumas que provavelmente nem são mais usadas. Os melhores exemplos não têm documentação, o que dificultaria a apreciação do padrão.

Além disso, não pode esquecer o amado

try{ 
   ... //many lines of likely dangerous operations
}
catch(Exception e){}

Um ex-colega de trabalho tinha o hábito de reutilizar objetos substituindo suas propriedades, em vez de simplesmente criar novas. Eu nunca poderia imaginar a quantidade de problemas que isso causou ao implementar novos recursos.

Algo que me causou muita dor é o padrão "Grande mapa no céu". Jogando em torno de um mapa em vez de usar objetos adequados. Você não tem idéia de quais "variáveis" ele contém sem depuração e não sabe o que pode conter sem rastrear o código para trás. Normalmente mapeia Strings para objetos ou Strings para Strings, que você potencialmente deve analisar em primitivas.

Um dos meus antipadrões de desenvolvimento favoritos é o uso de um "design" de banco de dados que requer a adição contínua de colunas adicionais a uma ou mais tabelas programaticamente . Este é um primo do "design" que cria uma nova tabela para cada instância de uma entidade. Ambos atingem inevitavelmente as limitações do servidor de banco de dados, mas geralmente não até que o sistema esteja em produção há algum tempo.

Eu acho que um dos piores anti-padrões que eu já vi envolve o uso de uma tabela de banco de dados como armazenamento temporário em vez de usar a memória do computador.

O domínio do problema é proprietário, o que me impede de explicá-lo, mas não é necessário entender o problema básico. Este era um aplicativo GUI escrito em Java com um banco de dados back-end. Era para pegar certos dados de entrada, manipulá-los e depois confirmar os dados processados ​​no banco de dados.

Nosso projeto possui um algoritmo bastante complicado que salva valores intermediários para processamento posterior. Em vez de encapsular os objetos temporários em ... objetos, uma tabela de banco de dados foi criada como "t_object". Sempre que um valor foi calculado, ele foi adicionado a esta tabela. Depois que o algoritmo terminasse seu trabalho, ele selecionaria todos os valores intermediários e os processaria em um objeto Map grande. Após o término de todo o processamento, os valores restantes marcados para serem salvos serão adicionados ao esquema real do banco de dados e as entradas temporárias na tabela "t_object" serão descartadas.

A tabela também foi usada como uma lista exclusiva, os dados só poderiam existir uma vez. Isso poderia ter sido um recurso decente do design se tivéssemos implementado restrições na tabela, mas acabamos iterando por toda a tabela para ver se os dados existiam ou não. (Não, nem usamos consultas que usavam cláusulas where com CONTAINS)

Alguns dos problemas que encontramos devido a esse design foram especificamente depuração. O aplicativo foi criado para pipeline de dados, para que houvesse várias GUIs que processariam os dados antes de chegarem nesse algoritmo. O processo de depuração foi processar um caso de teste e pausar logo após concluir a seção acima. Em seguida, consultávamos o banco de dados para ver quais dados estavam contidos nesta tabela.

Outro problema que descobrimos foi que os dados não estavam sendo excluídos corretamente dessa tabela temporária, o que interferiria com as execuções no futuro. Descobrimos que isso se deve ao fato de as exceções não serem tratadas adequadamente e, portanto, o aplicativo não sair corretamente e não excluir os dados na tabela em que estava sob controle.

Se tivéssemos usado o Design Orientado a Objetos Básico e mantivemos tudo na Memória, esses problemas acima nunca teriam ocorrido. Primeiro, a depuração seria simples, pois poderíamos configurar facilmente pontos de interrupção no aplicativo e depois inspecionar a memória na pilha e na pilha. Em segundo lugar, após uma saída anormal do aplicativo, a memória java teria sido limpa naturalmente sem ter que se preocupar em excluí-la do banco de dados.

NOTA: Não estou dizendo que esse padrão é inerentemente ruim, mas neste exemplo eu achei desnecessário quando os princípios básicos de OO seriam suficientes.

Não tenho certeza de um nome para esse anti-padrão, pois é a primeira vez que vejo algo assim sendo feito. Quaisquer bons nomes que vocês possam pensar para esse padrão?

Carrinho antes do cavalo - aka YouMightNeedIt

Por exemplo:

• Criando um esquema de RDMBs com conceitos abstratos, referências cruzadas - em essência um cubo de dados super generalizado ... E ENTÃO escrevendo recursos em torno de um modelo de tudo faz.

Na IMO, o pior antipadrão que já vi é o "Não precisamos de padrões fedorentos". Antipadrão: a ideia de que os padrões de design são desperdícios de tempo e você pode escrever código mais rapidamente, basta juntá-lo e copiar / colando conforme necessário.

Menção honrosa diz respeito ao código que carrega um objeto do banco de dados usando o antigo estilo VB6 de:

Foobar oFoo = new Foobar();
oFoo.FooID = 42;
if (oFoo.Load()) { 
    // do something with oFoo
}

não é realmente um antipadrão, por si só, mas mostra uma falta de tirar proveito da arquitetura adequada e da separação de preocupações.

Além disso, coisas assim:

// this name is misleading, we may not always want to stand in fire,
// we may want to stand in slime or voidzones or ice patches...
public Foobar StandInFire() { }

// why is this here???
public string BeatWithNerfBat(string whom) { }

// ????
public int GivePony(string to) { }