Qual é o nome do antipadrão em oposição a "reinventar a roda"? [fechadas]

101

O antipadrão " Reinventar a roda " é bastante comum - em vez de usar uma solução pronta, escreva a sua do zero. Base de código cresce desnecessariamente, ligeiramente diferentes interfaces que fazem a mesma coisa, mas ligeiramente diferente abundam, se perde tempo para escrever (e depuração!) Funções que estão prontamente disponíveis. Todos nós sabemos disso.

Mas há algo no extremo oposto do espectro. Quando, em vez de escrever sua própria função com duas linhas de código, você importa uma estrutura / API / biblioteca, instancia-a, configura-a, converte o contexto em tipo de dados como aceitável pela estrutura e chama essa única função que faz exatamente o que você precisa, duas linhas de lógica de negócios sob um gigabyte de camadas de abstração. E então você precisa manter a biblioteca atualizada, gerenciar dependências de compilação, manter as licenças sincronizadas e seu código de instanciação é dez vezes mais longo e mais complexo do que se você apenas "reinventasse a roda".

Os motivos podem ser variados: gerenciamento estritamente contrário à "reinvenção da roda", não importa o custo, alguém empurrando sua tecnologia preferida, apesar da sobreposição marginal com os requisitos, um papel cada vez menor de um antigo módulo do sistema, ou expectativa de expansão e expansão mais ampla uso da estrutura, que simplesmente nunca chega, ou apenas entendendo mal o "peso" que algumas instruções de importação / inclusão / carregamento carregam "nos bastidores".

Existe um nome comum para esse tipo de antipadrão?

(Não estou tentando iniciar uma discussão quando está certo ou errado, ou se é um antipadrão real ou qualquer coisa baseada em opiniões , essa é uma pergunta simples e objetiva da nomenclatura.)

Edit: o "duplicado" sugerido fala sobre o próprio código da superengenharia para torná-lo "pronto para tudo", completamente separado dos sistemas externos. Em certos casos, isso pode resultar disso, mas geralmente se origina da "aversão à reinvenção da roda" - reutilização de código a todo custo; se existir uma solução "pronta" para o nosso problema, nós a usaremos, não importando o quanto ela caiba e a que custo. Favorecendo dogmaticamente a criação de novas dependências em detrimento da duplicação de código, com total desconsideração dos custos de integração e manutenção dessas dependências quando comparados ao custo de criação e manutenção do novo código.

SF.
fonte
52
Dependência do inferno . É o mais próximo que consigo pensar.
Machado
5
@ Machado: Bom, embora eu diria que o Dependency Hell é o resultado direto da abundância desse antipadrão; no caso de sistemas extremamente complexos, pode ser um resultado direto da complexidade.
SF.
27
Eu chamaria isso de "dependência dependente" analógico para Feature_creep ou Scope_creep, onde mais e mais recursos originalmente indesejados são adicionados ao produto.
K3b
21
O fiasco do teclado esquerdo é um exemplo real da síndrome em ação.
SF.
13
Eu recomendo que começemos a nos referir coletivamente a isso como LeftPad.
precisa

Respostas:

9

Não. Não existe um nome anti-padrão comumente usado que cubra o que você está descrevendo.

JacquesB
fonte
4
Aparece com o número de idéias, sugestões e discussões que despertou; isso está realmente correto.
SF.
3
Estou me sentindo sujo fazendo isso.
SF.
Hã? "Não existe XXX" é uma afirmação muito forte e muito difícil de provar, especialmente considerando que há vários candidatos mencionados nos comentários.
AnoE
1
@AnoE "Existe um nome comum para esse tipo de antipadrão?" A evidência nos comentários e respostas mencionados implica fortemente que não existe. É verdade que não responde ao título, mas responde à pergunta em si.
Kroltan
@AnoE Você não pode provar um negativo, querida. Talvez o termo esteja escondido debaixo de uma pedra em Bornéu em algum lugar e ainda não o tenhamos caído? Que existem 10 respostas em vez de 1 com um zilhão de votos positivos é prova suficiente para mim.
49

Martelo de Ouro

O martelo de ouro é uma ferramenta escolhida apenas porque é chique. Não é econômico nem eficiente na execução da tarefa pretendida.

fonte: xkcd 801

(Apesar dos votos negativos, eu mantenho essa resposta. Pode não ser exatamente o oposto de reinventar a roda semanticamente, mas se encaixa em todos os exemplos mencionados na pergunta)

Martin
fonte
5
Upvoted, e você pode também adquirir-lo de wikipedia: en.wikipedia.org/wiki/Anti-pattern , en.wikipedia.org/wiki/Law_of_the_instrument
Pierre.Sassoulas
3
Eu rebaixaria isso se tivesse o representante. Ele não responde à pergunta como um todo, mas oferece um termo (preciso) que responde apenas a um dos cenários sugeridos.
David
3
Foi pedido o contrário. É como insistir que "Becquerel" (radiação, unidade é s ^ -1) possa ser usado para música, em vez de Hertz (hz, unidade é s ^ -1) porque ambos significam "por segundo".
Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Ouvi algumas músicas muito perigosas nos meus dias.
34

Robert Martin usa o termo " Framework Bound " para se referir às conseqüências negativas mais óbvias desse antipadrão. Como não acho que exista um nome comum para o próprio padrão, uma referência a essa conseqüência pode ser suficiente para a maioria dos propósitos.

Jules
fonte
1
Existem estruturas para acelerar o processo de desenvolvimento. Eles são como um foguete de reforço: gasto assim que usado. A solução é - versão um, agora onde estávamos? É isso mesmo, desenvolvendo software. Próximo! A manutenção é uma preocupação separada, e acho que não deve ser importante nos dias de hoje. Leve a próxima estrutura para a próxima solução, depois da pressa.
18

Esta página da wikipedia em " Inventado aqui " descreve uma situação ligeiramente diferente, mas com resultados finais muito semelhantes. Descreve a aversão de uma equipe em criar seu próprio código quando uma funcionalidade equivalente pode ser encontrada lá fora.

Eu diria que o nome é um pouco enganador. Faz sentido quando colocado em contexto com seu oposto. Não inventado aqui, que IMHO é praticamente um sinônimo de Reinventar a roda.

Newtopian
fonte
13

Eu ouvi " Buy Versus Build " e " Invented Here " como nomes antipadrão para um viés contra o desenvolvimento de coisas internamente, mesmo quando faz sentido fazê-lo. (E mesmo que a frase "comprar versus compilar" deva indicar uma escolha entre alternativas viáveis, acho que geralmente é mencionada quando alguém acredita que "comprar" é a escolha correta.)

amora
fonte
9

Não use um canhão para matar um mosquito

Confúcio

AKA Overkill

Rufus
fonte
5
A frase comum em inglês (Reino Unido) é "usar uma marreta para quebrar uma noz".
precisa saber é o seguinte
também: "caça ao veado com um tanque"
Jeutnarg
"Golpes voa com um martelo"
Não use um martelo para matar uma mosca
jeffmcneill
8

Bloat é um termo amplo, mas pode incluir o que você descreve. Nosso software se torna excessivamente complexo (inchado) devido a todas as transformações e abstrações extras necessárias, e a complexidade e as dependências contribuem para menor desempenho / menor eficiência e maior consumo de recursos (disco, largura de banda).

Se desejarmos, poderíamos esclarecer com um termo como dependências inchadas .

jpmc26
fonte
5

Eu acho que usar uma marreta para quebrar uma noz é bem próximo. É algo que é possível, mas precisa de uma quantidade excessiva de trabalho para quebrar uma porca dessa maneira, sem que ocorram muitos dos possíveis efeitos colaterais indesejados. (E há um saco inteiro de nozes para quebrar ...)

A frase também tem a vantagem de não estar computando o jargão, por isso pode ser muito útil para dar uma pista a alguém que não a possui.

A propósito, há uma distinção a ser traçada com o inferno da dependência . Se alguém já tiver envolvido todas as complexidades dentro de um encapsulamento que cria interfaces simples, claras e fáceis de usar, e desde que a penalidade nos ciclos da CPU ou no uso da memória não seja excessiva, é improvável que seja necessária uma modificação futura do código encapsulado necessário, então um argumento restante contra usá-lo é o inferno da dependência que pode estar causando.

nigel222
fonte
5

Não acho que exista um análogo exato, mas eu diria que o design excessivo ou a engenharia excessiva se aproximam.

Pelo menos, eu argumentaria que isso é o que realmente estava acontecendo quando encontrei algo semelhante ao que você descreve.

Usar uma biblioteca em vez de escrever seu próprio código para implementar a mesma funcionalidade quase nunca é prejudicial.

Mesmo em seu exemplo hipotético, o uso de uma biblioteca para substituir "duas linhas de código" pode não ser necessário, mas é improvável que lhe cause muito sofrimento - se for realmente uma biblioteca que pretende fazer o mesmo que suas duas linhas de código .

Uma biblioteca para fazer uma coisa simples também será simples. Não é provável que você tenha dores de cabeça que sua pergunta implica.

O uso de uma biblioteca complicada para fazer algo simples provavelmente implica que você está tentando fazer mais do que implementar a funcionalidade necessária.

Como criar recursos desnecessários, preparar-se para um futuro que talvez nunca venha, etc.

O problema aqui não é realmente falha em reinventar a roda em si .


fonte
4

Se você não reinventou a roda, provavelmente uma está usando um conjunto de rodas existente fornecido por um fornecedor ou por terceiros.

Se esse é um antipadrão, geralmente é chamado de bloqueio de fornecedor.

Jon Raynor
fonte
6
Eu realmente não sinto que é a mesma coisa. O aprisionamento do fornecedor é um resultado negativo específico da dependência da solução de um fornecedor, independentemente de o uso do fornecedor ser econômico ou não quando a escolha foi feita. O OP está mais perguntando sobre um termo para a escolha de uma solução de terceiros quando o custo de integração é maior que o custo de simplesmente desenvolver uma nova solução do zero (e o aprisionamento do fornecedor provavelmente nem está acontecendo, nos casos em que seria seja barato desenvolver uma nova solução em vez de confiar no fornecedor).
Ben
@ Ben - Ok, eu gosto do Framework vinculado em vez de bloquear o fornecedor melhor. Essa pergunta é baseada em opiniões e foi a primeira coisa que me veio à cabeça.
Jon Raynor
0

Seguro desemprego?
Você menciona todo o esforço de manter as coisas sincronizadas, etc. Algumas pessoas preferem gerenciar o código de outras pessoas a escrever o seu. Gerentes, especialmente.


fonte