Reinventare la ruota è davvero così male?

La sua conoscenza comune nella programmazione che reinventare la ruota è cattiva o cattiva .

Ma perché?

Non sto suggerendo che sia buono. Credo che sia sbagliato. Tuttavia, una volta ho letto un articolo che diceva che se qualcuno sta facendo qualcosa di sbagliato (programmazione saggia) spiega loro perché è sbagliato, se non puoi, allora forse dovresti chiederti se è davvero sbagliato.

Questo mi porta a questa domanda:

Se vedo qualcuno sta chiaramente reinventando la ruota costruendo il proprio metodo di qualcosa che è già incorporato nel linguaggio / quadro. Innanzitutto, per amor di argomenti, supponiamo che il loro metodo sia altrettanto efficace del metodo integrato. Anche lo sviluppatore, consapevole del metodo integrato, preferisce il proprio metodo.

Perché dovrebbe usare quello incorporato nel suo?

Come ho postato una volta su StackOverflow, reinventare la ruota è spesso un'ottima scelta , contrariamente alla credenza popolare. Il vantaggio principale è che hai il pieno controllo del software, che è spesso essenziale. Per una discussione completa, vedi il mio post originale .

Dipende ..

Come per tutto, riguarda il contesto:

Va bene quando:

• Il framework o la libreria sono troppo pesanti e sono necessarie solo funzionalità limitate. Realizzare la tua versione estremamente leggera adatta alle tue esigenze è un approccio migliore.
• Quando vuoi capire e imparare qualcosa di complesso, il tuo rotolamento ha senso.
• Hai qualcosa di diverso da offrire, qualcosa che le implementazioni altrui non hanno. Potrebbe essere una nuova svolta, una nuova funzionalità ecc.

È male quando:

• La funzionalità esiste già ed è nota per essere stabile e ben nota (popolare).
• La tua versione non aggiunge nulla di nuovo.
• La tua versione introduce bug o vincoli (ad es. La tua versione non è thread-safe).
• Nella tua versione mancano funzionalità.
• La tua versione ha una documentazione peggiore.
• Nella tua versione mancano i test unitari rispetto a ciò che sta sostituendo.

Penso che il caso di uno sviluppatore che reinventa consapevolmente la ruota "perché preferisce il suo metodo" è piuttosto raro. Principalmente è fatto per ignoranza e talvolta per testardaggine.

È tutto così male? Sì. Perché? Perché la ruota esistente è stata molto probabilmente costruita nel tempo ed è già stata testata in molte circostanze e contro molti tipi diversi di dati. Gli sviluppatori della ruota esistente hanno già riscontrato casi limite e difficoltà che il reinventatore non può ancora immaginare.

Le ruote quadrate devono essere reinventate. Gli sforzi che fanno schifo devono essere duplicati. Forse c'è una mancanza di documentazione per il metodo e l'altro programmatore ritiene che sia più semplice scrivere il proprio piuttosto che cercare di capirlo. Forse il modo in cui viene chiamato il metodo è imbarazzante e non si adatta al linguaggio del linguaggio di programmazione.

Chiedigli qual è la carenza.

In generale, evito di reinventare la ruota se la funzionalità che desidero, o qualcosa di simile ad essa, esiste nella libreria standard della lingua che uso.

Tuttavia, se devo incorporare librerie di terzi, è un appello di giudizio a seconda di quanto ampiamente usata e stimata sia la biblioteca. Voglio dire, stiamo parlando di Boost o Bob's Kick-ass String-Parsing Tools 1.0?

Anche se la biblioteca è generalmente ben nota e apprezzata in tutto il settore, è ancora una dipendenza di terze parti . I programmatori generalmente pongono un'enfasi significativa sulle virtù del riutilizzo del codice, mentre spesso sorvolano il pericolo delle dipendenze. Un progetto con troppe dipendenze di terze parti probabilmente cadrà a lungo termine mentre lentamente si trasforma in un incubo di manutenzione.

Quindi sfruttare il codice esistente è buono , ma le dipendenze sono cattive . Sfortunatamente, queste due affermazioni sono in contrasto tra loro, quindi il trucco sta cercando di trovare il giusto equilibrio. Ecco perché è necessario identificare dipendenze accettabili . Come ho detto, qualsiasi cosa nella Libreria standard della lingua è molto probabilmente una dipendenza accettabile. Passando da lì, librerie che sono altamente considerati in tutto il settore sono generalmente accettabili (come Boost per C ++, o jQuery per Javascript) - ma sono ancora meno desiderabile della libreria standard, perché non tendono ad essere meno stabile di librerie standardizzate .

Per quanto riguarda le librerie che sono relativamente sconosciute, (ad esempio l'ultimo caricamento su SourceForge), si tratta di dipendenze estremamente rischiose, e generalmente consiglierei di evitarle nel codice di produzione, a meno che tu non abbia abbastanza familiarità con il codice sorgente per mantenerle tu stesso.

Quindi è davvero tutto un atto di bilanciamento. Ma il punto è che basta dire alla cieca "Riutilizzare il codice bene! Reinventare la ruota è male!" è un atteggiamento pericoloso. I vantaggi di sfruttare il codice di terze parti devono essere valutati rispetto agli svantaggi dell'introduzione delle dipendenze.

Se le persone non reinventassero le ruote, il mondo sarebbe pieno di questi ...

Ecco un dialogo dal mio posto di lavoro:

- I would like to add some colors to the output of this program.
- Oh, there is this library called Colorama ..

Esistono due opzioni: reinventare la ruota o utilizzare Colorama. Ecco cosa comporterebbe ogni opzione:

Usando Colorama

• Forse un po 'più veloce per iniziare a correre
• Aggiunta di una dipendenza di terze parti per qualcosa di banale
• Continui a essere stupido come prima di usare Colorama

Reinventare la ruota

• Capisci come alcuni programmi sono in grado di mostrare il colore
• Si impara che i caratteri speciali possono essere utilizzati per colorare su qualsiasi terminale
• Sei in grado di colorare qualsiasi linguaggio di programmazione che potresti utilizzare in futuro
• Il tuo progetto ha meno probabilità di rompersi

Come vedi, dipende tutto dal contesto. Reinventare la ruota è qualcosa che faccio molto spesso perché voglio essere capace e pensare per me stesso e non fare affidamento su altre persone che pensano per me. Se tuttavia stai eseguendo una scadenza o ciò che cerchi di implementare è enorme ed esiste già, allora stai meglio usando ciò che è lì.

Un motivo utile per reinventare la ruota è a fini di apprendimento, ma ti consiglio di farlo nel tuo tempo libero. Man mano che diventano disponibili più soluzioni preconfezionate e vengono forniti più livelli di astrazione, diventiamo molto più produttivi. Possiamo concentrarci sul problema aziendale piuttosto che sulle cose generiche che sono state modificate più volte. MA, per questo motivo, puoi affinare le tue abilità e imparare molto cercando di implementare una soluzione da solo. Solo non necessariamente per l'uso in produzione.

Un'altra cosa: se una preoccupazione è la dipendenza da una libreria di terze parti di un'azienda che potrebbe scomparire, assicurati che ci sia un'opzione per ottenere il codice sorgente o almeno un paio di altre opzioni là fuori su cui ripiegare.

A proposito, se scegli di implementare il tuo, evita di farlo per la crittografia o altre funzionalità relative alla sicurezza. Per questo sono disponibili strumenti affermati (e completamente testati), e al giorno d'oggi è troppo rischioso farli da soli. Non ne vale la pena, ed è spaventoso che io sappia ancora che le squadre lo fanno.

Esistono due tipi di efficienza: elaborazione / velocità (ovvero la velocità con cui viene eseguita) che può corrispondere e velocità di sviluppo che quasi sicuramente non lo farà. Questo è il primo motivo: per qualsiasi problema di ragionevole complessità in cui siano disponibili soluzioni esistenti, sarà quasi sicuramente più veloce ricercare e implementare una libreria esistente piuttosto che codificare la propria .

Il secondo motivo è che la libreria esistente (supponendo che sia matura) è testata e ha dimostrato di funzionare - probabilmente in una gamma molto più ampia di scenari rispetto a uno sviluppatore e un team di test sarà in grado di mettere a punto una routine appena scritta e questo arriva a zero sforzi.

In terzo luogo, è molto più semplice da supportare. Non solo qualcun altro lo supporta e lo migliora (chiunque abbia scritto la libreria / componente), ma è molto più probabile che altri sviluppatori lo conoscano e siano in grado di comprendere e mantenere il codice in futuro , tutto ciò minimizza in corso costi.

E tutto ciò presuppone l'equivalenza funzionale, che normalmente non è il caso. Spesso le biblioteche offriranno funzionalità che potresti trovare utili ma che non potrebbero mai giustificare la costruzione, tutte improvvisamente disponibili gratuitamente.

Ci sono ragioni per fare il tuo - in gran parte dove vuoi fare qualcosa che la funzione integrata non può fare e dove c'è un vero vantaggio da guadagnare nel farlo, o dove le opzioni prontamente disponibili non sono mature - ma loro sei meno comune di quanto molti sviluppatori vorrebbero farti credere.

Inoltre, perché vorresti passare il tempo a risolvere problemi che sono già stati risolti? Sì, è un ottimo modo per imparare, ma non dovresti farlo a costo della giusta soluzione per il codice di produzione, che è ciò di cui presumo che stiamo parlando.

Ovviamente reinventare la ruota per un capriccio, per ignoranza e arroganza può essere una brutta cosa, ma IMHO il pendolo ha oscillato troppo. C'è un enorme vantaggio nell'avere una ruota che fa esattamente quello che vuoi e niente di più .

Spesso quando guardo una ruota esistente, o fa molto più di quanto ne abbia bisogno, soffre dell'effetto piattaforma interna ed è quindi inutilmente complessa, oppure manca qualche caratteristica chiave di cui ho bisogno e che sarebbe difficile implementare in cima a ciò che è già lì.

Inoltre, l'uso di ruote esistenti spesso aggiunge al mio progetto vincoli che non voglio. Per esempio:

• La ruota esistente richiede un linguaggio e / o uno stile di programmazione diversi da quelli che altrimenti preferirei utilizzare.
• La ruota esistente funziona solo con la versione legacy di un linguaggio (ad esempio, Python 2 anziché Python 3).
• Laddove vi sono compromessi tra efficienza, flessibilità e semplicità, la ruota esistente fa delle scelte non ottimali per il mio caso d'uso. (Sono stato conosciuto per reinventare persino la funzionalità delle librerie che in origine ho scritto da solo in questi casi. Di solito è perché ho scritto che la versione della libreria della funzione è generica e ragionevolmente efficiente, quando al momento ho bisogno di qualcosa che sia molto veloce nel mio specifico Astuccio.)
• La ruota esistente ha tonnellate di legacy legft che sono totalmente inutili nel caso del nuovo codice ma rendono comunque la vita difficile (ad esempio, una libreria Java che uso che mi costringe a usare le sue scadenti classi di container perché è stata scritta prima dei generici, ecc.) .
• Il modo in cui la ruota esistente modella il problema è completamente diverso da quello che è conveniente per il mio caso d'uso. (Ad esempio, forse è conveniente per me avere un grafico diretto rappresentato da oggetti nodo e riferimenti, ma la ruota esistente utilizza una matrice di adiacenza o viceversa. Forse è conveniente per me disporre i miei dati nell'ordine principale della colonna, ma il la ruota esistente insiste sulla fila maggiore o viceversa.)
• La libreria aggiunge un'enorme, fragile dipendenza che sarebbe una seccatura maggiore per iniziare e funzionare ovunque io voglia distribuire il mio codice, quando tutto ciò di cui ho bisogno è un piccolo sottoinsieme delle sue funzionalità. D'altra parte, in questo caso a volte estraggo la funzione che desidero in una nuova libreria più piccola o semplicemente copia / incolla se la libreria è open source e la base di codice lo rende sufficientemente semplice. (L'ho anche fatto con librerie relativamente grandi che ho scritto da solo, non solo da altre persone.)
• La ruota esistente tenta di essere pedanticamente conforme ad alcuni standard che sono sia scomodi che irrilevanti per il mio caso d'uso.

Spesso uso il mio perché l'ho costruito prima di scoprire quello preesistente e sono troppo pigro per andare a cercare e sostituire ogni istanza. Inoltre, capisco perfettamente il mio metodo mentre potrei non capirne uno preesistente. E infine, poiché non capisco completamente quello preesistente, non posso verificare che faccia assolutamente tutto ciò che fa quello attuale.

C'è molto da programmare e non ho molto tempo per tornare indietro e ricodificare qualcosa a meno che non abbia un impatto sulla produzione.

In effetti, un'app Web ASP ancora utilizzata oggi ha un grafico completamente funzionale che visualizza i dati in un formato tabulare e consente l'ordinamento / modifica, tuttavia non è un datagrid. È stato costruito alcuni anni fa quando stavo imparando per la prima volta asp.net e non conoscevo i datagrid. Ho un po 'paura del codice poiché non ho idea di cosa stavo facendo allora, ma funziona, è accurato, è facile da modificare, non si arresta in modo anomalo e gli utenti lo adorano

Reinventare la ruota è un ottimo modo per imparare come funziona una ruota, ma non è un buon modo per costruire un'auto.

Attualmente lavoro per un gruppo di cheapskates.

Quando viene presa la decisione tra "costruire o comprare", invece di prendere una decisione razionale basata sull'economia, i gestori scelgono di "costruire". Ciò significa che invece di pagare qualche migliaio di dollari per un componente o uno strumento, passiamo mesi-uomo a costruire il nostro. L'acquisto di una ruota da un'altra società costa denaro che viene fuori dal budget, il che conta per i bonus di fine anno. Il tempo dei programmatori è gratuito e quindi non conta per i bonus di fine anno (con l'ulteriore vantaggio di perdere i programmatori per non fare tutto "in tempo"), quindi una ruota reinventata è una ruota libera .

In un'azienda razionale, il costo rispetto ai vantaggi dell'acquisto di ruote fatte da altri rispetto al reinventare le proprie ruote si baserebbe sui costi a breve e lungo termine, nonché sui costi opportunità persi perché non si possono fare nuovi widget mentre si è reinventare le ruote. Ogni giorno che passi per reinventare la ruota è un altro giorno in cui non puoi scrivere qualcosa di nuovo.

Presentazione su build vs acquisto .
Articolo su build vs buy .

Se vedo qualcuno sta chiaramente reinventando la ruota costruendo il proprio metodo di qualcosa che è già incorporato nel linguaggio / quadro. Innanzitutto, per amor di argomenti, supponiamo che il loro metodo sia altrettanto efficace del metodo integrato. Anche lo sviluppatore, consapevole del metodo integrato, preferisce il proprio metodo.

Perché dovrebbe usare quello incorporato nel suo?

La versione integrata avrà avuto molte più persone che ci sbattevano sopra, trovando e correggendo più bug di quanti il ​​tuo codice homebrew possa mai avere.

Alla fine, quando il tuo sviluppatore locale lascia, e qualcun altro deve mantenere il codice che ha scritto, verrà completamente rifatto e sostituito con ciò che è nel framework. So che questo accadrà perché il mio attuale datore di lavoro ha un codice che è stato migrato nelle versioni più recenti di VB nel corso degli anni (il prodotto più vecchio è sul mercato da circa 20 anni) e questo è ciò che è successo. Lo sviluppatore con il lavoro più lungo nel mio ufficio è qui da 17 anni.

La cosa nuova di reinventare la ruota è che a volte non esiste una ruota standard standard che farà ciò di cui hai bisogno. Ci sono molte buone ruote là fuori, in molte dimensioni, colori, materiali e modalità di costruzione. Ma alcuni giorni devi solo avere una ruota davvero leggera che è in alluminio anodizzato verde, e nessuno lo fa. In tal caso, DEVI crearne uno tuo.

Questo non vuol dire che dovresti creare le tue ruote per ogni progetto: la maggior parte delle cose può usare parti standard ed essere migliore per questo. Ma di tanto in tanto, scopri che le parti standard non funzionano, quindi ne fai le tue.

La cosa più importante è sapere QUANDO crearne uno tuo. Devi avere una buona idea di cosa possono fare le parti standard e cosa non possono fare, prima di iniziare a progettare le tue.

Se reinventare o meno la ruota è una questione di costi / benefici. I costi sono abbastanza ovvi ...

• Ci vuole molto tempo per reinventare.
• Ci vuole ancora più tempo per documentare ciò che hai inventato.
• Non puoi assumere persone che già comprendono ciò che hai inventato.
• È fin troppo facile reinventare qualcosa di male, causando costi continui per i problemi causati dalla cattiva progettazione.
• Nuovo codice significa nuovi bug. Il vecchio codice di solito ha già rimosso la maggior parte dei bug e potrebbe avere soluzioni alternative a problemi di cui non si è a conoscenza e quindi non è possibile aggirare il nuovo design.

L'ultimo è importante: c'è un post sul blog che avverte da qualche parte della tendenza a "buttare via il vecchio codice e ricominciare da zero" sulla base del fatto che molte delle vecchie truppe che non capisci sono in realtà correzioni di bug essenziali. C'è una storia di ammonimento su Netscape, IIRC.

I vantaggi possono essere ...

• La possibilità di aggiungere funzionalità che non hanno le librerie esistenti. Ad esempio, ho contenitori che "mantengono" le loro istanze iteratore / cursore. Inserimenti ed eliminazioni non invalidano gli iteratori. Un iteratore che punta su un vettore continuerà a puntare allo stesso elemento (non allo stesso indice) indipendentemente dagli inserimenti e dalle eliminazioni precedenti nel vettore. Semplicemente non puoi farlo con i contenitori C ++ standard.
• Un design più specializzato che si rivolge alle tue esigenze particolari e rispetta le tue priorità (ma fai attenzione alla tendenza verso l'effetto della piattaforma interna).
• Controllo completo: alcune terze parti non possono decidere di ridisegnare l'API in modo da riscrivere metà dell'applicazione.
• Comprensione completa: l'hai progettata in questo modo, quindi speri di comprendere appieno come e perché lo hai fatto.
• MODIFICA Puoi imparare le lezioni da altre biblioteche senza essere catturato nelle stesse trappole essendo selettivo su come le imiti.

Una cosa: usare una libreria di terze parti può essere considerato come reinventare la ruota. Se hai già la tua libreria antica, ben utilizzata e ben collaudata, pensa attentamente prima di scartarla per utilizzare invece una libreria di terze parti. A lungo termine potrebbe essere una buona idea, ma prima che tu ci arrivi ci può essere un enorme lavoro e molte brutte sorprese (da sottili differenze semantiche tra le biblioteche). Ad esempio, considera l'effetto del passaggio dai miei contenitori a quelli delle librerie standard. Una traduzione ingenua del codice chiamante non consentirebbe il fatto che i contenitori della libreria standard non mantengano i loro iteratori. I casi in cui in seguito conservo un iteratore come "segnalibro" non possono essere implementati utilizzando una semplice traduzione - I '

Se esiste un componente funzionante che fa ciò di cui hai bisogno, perché perdere tempo a scrivere e eseguire il debug della tua versione? Allo stesso modo, se hai già scritto codice per svolgere una funzione simile in precedenza, perché riscriverlo?

Joel ha scritto un articolo su Non-inventato-qui che parla di volumi su quando riscrivere codice e software non è e non è utile.

Reinventare la ruota può essere un ottimo modo per imparare come funziona qualcosa - e raccomando di reinventare proprio per quello scopo nel tuo tempo libero - ma quando scrivi un'applicazione perché reinventare se ci sono soluzioni consolidate che già fanno la stessa cosa?

Ad esempio, non scriverei mai il codice JavaScript da zero; invece vorrei iniziare con jQuery e costruire le mie applicazioni su quel framework.

La mia regola empirica personale:

Reinventare la ruota è buono quando stai solo imparando. Se hai una scadenza, potresti voler usare le ruote esistenti.

Essere "cattivo" o addirittura "cattivo" è parole piuttosto forti.

Come sempre ci sono ragioni per scegliere un'implementazione personale piuttosto che incorporata. In passato un programma C poteva riscontrare bug nella libreria di runtime e quindi doveva semplicemente fornire la propria implementazione.

Ciò non si applica ai programmi Java poiché la JVM è definita in modo molto rigoroso, ma alcuni algoritmi sono ancora molto difficili da ottenere. Ad esempio, Joshua Bloch descrive come l'algoritmo di ricerca binaria ingannevolmente semplice nella libreria di runtime Java contenesse un bug, che ci sono voluti nove anni per emergere:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html

È stato trovato, riparato e distribuito nelle future distribuzioni Java.

Se usi la ricerca binaria integrata, hai appena risparmiato tempo e denaro facendo in modo che Sun faccia il duro lavoro per trovare, correggere e distribuire questo bugfix. Puoi sfruttare il loro lavoro semplicemente dicendo "devi avere almeno Java 6 aggiornamento 10".

Se usi la tua implementazione - che molto probabilmente conterrebbe anche questo errore - devi prima manifestare il bug. Dato che questo particolare viene mostrato solo su GRANDI set di dati, è destinato ad accadere nella produzione da qualche parte, il che significa che almeno uno dei tuoi clienti sarà interessato e molto probabilmente perderà denaro reale mentre trovi, risolvi e distribuisci il bugfix.

Quindi, è perfettamente valido preferire la propria implementazione, ma è meglio che la ragione sia davvero buona, poiché è destinata ad essere più costosa rispetto a sfruttare il lavoro degli altri.

Di recente ho scritto un blog sui miei pensieri su questo argomento. Riassumere:

1. Costruire il tuo è quasi sempre malvagio, specialmente se è una funzione incorporata nel linguaggio. Ma se stai valutando un framework immaturo / gestito in modo discutibile / mal documentato che hai trovato su Internet contro la possibilità di scriverne uno tuo, potrebbe essere un gioco da ragazzi.

2. Penso che reinventare la ruota sia un'analogia piuttosto terribile per un anti-schema software. Implica che la soluzione originale non può mai essere migliorata. Questa è una sciocchezza. La cosiddetta ruota può diventare obsoleta durante la notte, oppure i suoi proprietari potrebbero smettere di mantenerla. La ruota ha un valore diverso in ciascun sistema in cui viene utilizzata. Quindi, è spesso del tutto possibile inventare una ruota migliore.

3. Uno dei maggiori vantaggi di creare il proprio framework è che non dovrai assumerti la responsabilità dei bug di qualcun altro. (Questa è la filosofia di Amazon .) Pensaci in questo modo: quale di questi è meglio dire a un cliente? -

   "Il nostro sito Web si è rotto. È stata colpa di qualcun altro e abbiamo registrato un bug con il suo creatore. Non possiamo farci altro che aspettare. Ti terremo aggiornato."

   "Il nostro sito Web si è rotto e siamo riusciti a risolverlo immediatamente."

Forse è altrettanto efficiente, ma è altrettanto robusto? Penso che la ragione più convincente per usare una libreria oltre a farla propria sia che il framework ha così tante persone che la usano che possono trovare e correggere rapidamente i bug. Le librerie sviluppate internamente, sebbene possano fornire altrettante (o più) funzionalità, non possono competere con una libreria con milioni di utenti per fornire test praticamente in ogni caso d'uso. Non puoi battere quel tipo di test internamente.

Bene, il suo metodo essendo efficiente quanto il framework sarebbe piuttosto raro perché la maggior parte dei framework ha ancora dei bug e nessun framework può darti una soluzione pronta all'uso. La maggior parte dei programmatori che non riescono a pensare non proveranno mai a scrivere nulla a livello di framework; cercheranno semplicemente su Google una soluzione pronta. Qualsiasi programmatore saggio prima vedrà se esiste un framework gratuito con le funzionalità di cui ha bisogno, quindi scriverà la soluzione se non lo è. A volte è troppo difficile spiegare l'attuale situazione del progetto e lo sviluppatore è il miglior giudice.

Reinventare la ruota non è male, è una dichiarazione fatta da persone pigre per evitare di lavorare sodo. Perfino gli scrittori di quadri reinventano; l'intero framework .Net è stato reinventato per fare ciò che COM stava offrendo.

Per quanto offensivo possa essere per alcuni, ho sempre trovato questo termine come non-amato quando usato da qualsiasi forma di ingegnere o in riferimento a un argomento di creazione o progettazione di cose. In realtà, non posso fare a meno di vederlo come disgustoso se si considerano le pressioni per innovare nel mondo frenetico di oggi. Ripetersi (o ignorare adeguate soluzioni preesistenti) non è mai saggio, ma in realtà c'è un motivo per cui non stiamo ancora fissando schermi neri pieni di lettere verdi.

Capisco "Se non è rotto non aggiustarlo", anche se immagino che una frase del genere possa sembrare ignorante per alcuni. Tuttavia, con l'attuale sforzo di reinventare la ruota per le esigenze di viaggio nello spazio, corsa, spedizione, ecc., "Non reinventare la ruota" è anche abbastanza ignorante, e non è affatto intelligente come sembra.

Il mio background consiste nel guidare molti progetti e ho dovuto lavorare con molti stagisti e altre forme di sviluppatori verdi, e ho dovuto gestire molte domande ingenue che alcuni chiamerebbero "stupide", e ho anche dovuto distogliere la gente dall'inseguire il coniglio interi al di fuori dell'ambito dei loro compiti. Tuttavia, non scoraggerei mai l' innovazione o la creatività e ho visto grandi cose venire dal "reinventare la ruota".

La mia vera risposta alla domanda: ci sono solo due situazioni che fanno reinventare la ruota è una brutta cosa:

1. Se non è davvero necessario
2. Se è l'altro che lo fa quando puoi

Modifica: vedo dai voti negativi che devo aver offeso alcuni. L'unica cosa che vorrei aggiungere è che questa frase è sempre stata una mia grande pepita. Capisco che i miei due centesimi potrebbero sembrare piuttosto trollish, ma non ho intenzione di troll, provocare incendi o offendere.

Gli argomenti su "reinventare una ruota" sono spesso usati nel contesto sbagliato della scelta di usare una biblioteca, ma non è una cosa simile.

Diciamo che sto valutando una libreria 'form-plus', che è diventata popolare di recente e aiuta a gestire i moduli. Ha una bella landing page, una grafica moderna e accattivante e una -cult- (oops intendo comunità) che giurano come rendere di nuovo grandi le forme. Ma "forme-più" è un'astrazione in cima a "forme". le "forme" erano possibili ma ingombranti da affrontare, così l'astrazione che rende più facile sta diventando popolare.

Nuove astrazioni stanno accadendo tutto il tempo. È difficile confrontarli con le ruote. È più come un nuovo dispositivo di controllo e un nuovo manuale per qualsiasi dispositivo già molto complicato che devi eseguire.

La valutazione di questo nuovo dispositivo "forme-plus" avrà un aspetto diverso a seconda dell'esperienza personale. Se non avessi mai creato moduli prima di allora, "forms-plus" sarebbe molto interessante perché è più facile iniziare. Il rovescio della medaglia è che se "forme-più" si rivela essere un'astrazione che perde, dovrò comunque imparare "forme" comunque. Se stavo costruendo moduli senza "form plus", dovrò prendere in considerazione il tempo necessario per apprendere nuovi strumenti. Il lato positivo è che conosco già le "forme", quindi non ho paura delle astrazioni. I benefici a breve termine saranno spesso maggiori per i nuovi principianti perché probabilmente non ci sarebbe una nuova biblioteca se non migliorasse su qualcosa. I benefici a lungo termine varieranno ampiamente in base alla qualità dell'astrazione, al tasso di adozione,

Dopo aver valutato attentamente i vantaggi e gli aspetti negativi dell'utilizzo di una nuova astrazione "forme più" rispetto all'utilizzo di "forme" di osso nudo, prendo una decisione. La decisione è fortemente basata sulle mie esperienze personali e persone diverse prenderanno decisioni diverse. Avrei potuto scegliere di usare "forme" a ossa nude. Forse più tardi nel tempo le forme-plus avevano guadagnato più movimento e diventando uno standard defacto. E forse la mia implementazione nel tempo è diventata pelosa e ha iniziato a coprire molto ciò che forme-plus ora sta facendo. Le persone che verranno in questo momento saranno attratte dalla critica per il fatto che sono entusiasta di reinventare la ruota e che invece avrei dovuto usare la libreria esistente. Ma è anche possibile che al momento in cui dovevo prendere una decisione su "forme-più" c'erano anche molte altre alternative a "forme-più",

Alla fine, scegliere gli strumenti giusti è una decisione complicata da prendere e la "reinvenzione della ruota" non è una prospettiva molto utile.

Ho scritto un piccolo articolo a riguardo - http://samueldelesque.tumblr.com/post/77811984752/what-re-inventing-the-wheel-can-teach-you

Nella mia esperienza, reinventare è stato davvero fantastico, anche se molto lungo e noioso. Direi che se non conosci esattamente i modelli di programmazione che intendi utilizzare, scrivili tu (se hai tempo ed energia). Questo ti insegnerà cosa significano esattamente quei modelli di programmazione e alla fine diventerai un programmatore migliore. Naturalmente, se stai lavorando per un cliente e hai solo bisogno di fare qualcosa rapidamente, probabilmente vorrai solo fare qualche ricerca e trovare il software giusto per te.