Qual è il nome dell'antipasto opposto a "reinventare la ruota"? [chiuso]

L' antipasto " Reinvent the wheel " è piuttosto comune - invece di usare una soluzione pronta, scrivi il tuo da zero. La base di codice cresce inutilmente, interfacce leggermente diverse che fanno la stessa cosa ma in modo leggermente diverso abbondano, si perde tempo a scrivere (ed eseguire il debug!) Funzioni che sono prontamente disponibili. Lo sappiamo tutti.

Ma c'è qualcosa dall'altra parte dello spettro. Quando invece di scrivere la propria funzione che è due righe di codice, si importa un framework / API / libreria, si crea un'istanza, si configura, si converte il contesto in tipo di dati come accettabile dal framework, quindi si chiama quella singola funzione che fa esattamente ciò di cui si ha bisogno, due linee di logica aziendale sotto un gigabyte di strati di astrazione. E quindi è necessario mantenere la libreria aggiornata, gestire le dipendenze di compilazione, mantenere le licenze sincronizzate e il codice di istanza di essa è dieci volte più lungo e più complesso di se si "reinventasse la ruota".

Le ragioni possono essere diverse: la gestione si oppone rigorosamente alla "reinvenzione della ruota" a prescindere dal costo, qualcuno che spinge la sua tecnologia preferita nonostante la sovrapposizione marginale con i requisiti, un ruolo decrescente di un modulo precedentemente importante del sistema o l'aspettativa di espansione e più ampia l'uso del framework, che non arriva mai, o semplicemente fraintende il "peso" che un paio di istruzioni import / include / load portano "dietro le quinte".

C'è un nome comune per questo tipo di antipattern?

_{(Non sto cercando di iniziare una discussione quando è giusto o sbagliato, o se è un vero antipasto o qualcosa basato sull'opinione , questa è una semplice domanda di nomenclatura semplice e obiettiva.)}

Modifica: il "duplicato" suggerito parla di sovrastima del proprio codice per renderlo "pronto a tutto", completamente separato dai sistemi esterni. In alcuni casi questa cosa potrebbe derivare da essa, ma generalmente deriva da "avversione al reinventare la ruota" - riutilizzo del codice a tutti i costi; Se una soluzione "chiavi in mano" per il nostro problema esiste, ci sarà usarlo, non importa quanto male si adatta ea quali costi si tratta. Favorire dogmaticamente la creazione di nuove dipendenze rispetto alla duplicazione del codice, con totale disprezzo per i costi di integrazione e manutenzione di queste dipendenze rispetto ai costi di creazione e manutenzione del nuovo codice.

No. Non esiste un nome anti-pattern comunemente usato che copre ciò che stai descrivendo.

Martello d'oro

Il martello d'oro è uno strumento scelto solo perché è elegante. Non è né conveniente né efficiente nell'esecuzione dell'attività prevista.

fonte: xkcd 801

(Nonostante i voti negativi, sostengo questa risposta. Potrebbe non essere esattamente l'opposto di reinventare la ruota semanticamente, ma si adatta a tutti gli esempi citati nella domanda)

Robert Martin usa il termine " Framework Bound " per riferirsi alla più ovvia conseguenza negativa di questo anti-pattern. Poiché non credo che ci sia un nome comune per il modello stesso, un riferimento a questa conseguenza potrebbe essere sufficiente per la maggior parte degli scopi.

Questa pagina di Wikipedia su " Invented Here " descrive una situazione leggermente diversa ma con risultati finali molto simili. Descrive l'avversione di una squadra verso la creazione del proprio codice quando si possono trovare funzionalità equivalenti là fuori.

Direi che il nome è un po 'fuorviante però. Ha senso quando viene messo in contesto con il suo opposto Not Invented Here che IMHO è praticamente un sinonimo di Reinventing the wheel.

Ho sentito " Buy Versus Build " e " Invented Here " come nomi anti-pattern per una propensione a sviluppare le cose internamente, anche quando può avere senso farlo. (E anche se la frase "compra contro build" dovrebbe indicare una scelta tra alternative praticabili, trovo che di solito sia menzionata quando qualcuno crede che "comprare" sia la scelta corretta.)

Non usare un cannone per uccidere una zanzara

Confucio

AKA Overkill

Bloat è un termine generico , ma può includere ciò che descrivi. Il nostro software diventa eccessivamente complesso (gonfio) a causa di tutte le trasformazioni e le astrazioni aggiuntive richieste e sia la complessità che le dipendenze stesse contribuiscono a ridurre le prestazioni / meno efficienza e un consumo di risorse più elevato (disco, larghezza di banda).

Se lo desideriamo, potremmo chiarire con un termine come dipendenze gonfie .

Penso che usare una mazza per rompere un dado sia abbastanza vicino. È qualcosa che è possibile, ma ha bisogno di una quantità eccessiva di lavoro per rompere un dado in quel modo, senza che si verifichino numerosi possibili effetti collaterali indesiderati. (E c'è un sacco di noci da rompere ...)

La frase ha anche il vantaggio che non sta calcolando il gergo, quindi può essere molto utile nel fornire un indizio a qualcuno che non ne ha.

A proposito, c'è una distinzione da tracciare con l' inferno delle dipendenze . Se qualcuno ha già racchiuso tutte le complessità all'interno di un incapsulamento che crea interfacce semplici, chiare e facili da usare e ha fornito la penalità nei cicli della CPU o nell'utilizzo della memoria non eccessiva, e è improbabile che le future modifiche del codice incapsulato siano necessario, quindi un argomento rimanente contro l'utilizzo è l'inferno di dipendenza che potrebbe causare.

Non credo che esista un analogo esatto, ma direi che il design eccessivo o l'ingegnerizzazione eccessiva si avvicinano.

Almeno, direi che questo è ciò che stava realmente accadendo quando ho incontrato qualcosa di simile a quello che descrivi.

Utilizzare una libreria invece di scrivere il proprio codice per implementare la stessa funzionalità non è quasi mai dannoso.

Anche nel tuo esempio ipotetico, l'uso di una libreria per sostituire "due righe di codice" potrebbe non essere necessario, ma è improbabile che ti causi molto dolore - se è davvero una libreria destinata a fare la stessa cosa delle tue due righe di codice .

Una libreria per fare una cosa semplice sarà anche semplice. Non è probabile che ti dia il mal di testa che implica la tua domanda.

Usare una libreria complicata per fare qualcosa di semplice probabilmente implica che stai cercando di fare qualcosa di più che implementare la funzionalità richiesta.

Come funzioni integrate che non sono necessarie, prepararsi per un futuro che potrebbe non arrivare mai, ecc.

Il problema qui non è proprio l'incapacità di reinventare la ruota di per sé .

Se non hai reinventato la ruota, molto probabilmente si sta utilizzando un set di ruote esistente fornito da un fornitore o da terze parti.

Se si tratta di un modello anti-pattern, in genere viene chiamato blocco del fornitore.

Sicurezza sul lavoro?
Lei menziona tutti gli sforzi per mantenere le cose sincronizzate, ecc. Alcune persone preferiscono gestire il codice di altre persone piuttosto che scriverne uno proprio. I gestori, in particolare.