Sta reinventando la ruota davvero così male?

Come una volta ho postato su StackOverflow, reinventare la ruota è spesso un'ottima scelta , contrariamente a quanto si crede. Il vantaggio principale è che hai controllo completo sul software, che è spesso essenziale. Per una discussione completa, guarda il mio post originale .

Dipende ..

Come tutto, è relativo al contesto:

È buono quando:

• Il framework o la libreria sono troppo pesanti e richiedono solo funzionalità limitate. Rollare la tua versione estremamente leggera che soddisfa le tue esigenze è un approccio migliore.
• Quando vuoi capire e imparare qualcosa di complesso, il tuo modo di procedere ha un senso.
• Hai qualcosa di diverso da offrire, qualcosa che le implementazioni degli altri non hanno. Può essere una novità, una nuova funzionalità ecc.

È brutto quando:

• La funzionalità esiste già ed è nota per essere stabile e ben conosciuta (popolare).
• La tua versione non aggiunge nulla di nuovo.
• La tua versione introduce bug o vincoli (ad es. la tua versione non è thread-safe).
• La tua versione manca di 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 proprio metodo" è piuttosto raro. Principalmente è fatto per ignoranza e talvolta per testardaggine.

È tutto così male? Sì. Perché? Poiché la ruota esistente è stata probabilmente realizzata nel tempo ed è già stata testata in molte circostanze e contro molti diversi tipi di dati. Gli sviluppatori della ruota esistente hanno già incontrato i casi limite e le difficoltà che il reinventore non riesce nemmeno a immaginare.

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

Basta chiedergli qual è la carenza.

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

Tuttavia, se devo incorporare librerie di terze parti, si tratta di una sentenza in base a quanto è ampiamente utilizzata e stimata la libreria. Voglio dire, stiamo parlando di Boost o di Bob's Kick-ass String-Parsing Tools 1.0?

Anche se la biblioteca è generalmente ben nota e molto apprezzata in tutto il settore, è ancora una dipendenza di terze parti . I programmatori in genere pongono l'accento sulle virtù del riutilizzo del codice, mentre spesso sorvolo sul pericolo delle dipendenze. Un progetto con troppe dipendenze di terze parti rischia di crollare a lungo andare mentre lentamente si trasforma in un incubo di manutenzione.

Quindi sfruttare il codice esistente è buono - ma le dipendenze sono non buone . Sfortunatamente, queste due affermazioni sono in disaccordo l'una con l'altra, quindi il trucco sta cercando di trovare il giusto equilibrio. Ecco perché è necessario identificare le dipendenze accettabili . Come ho detto, qualsiasi cosa nella Biblioteca standard della lingua è molto probabilmente una dipendenza accettabile. Passando da lì, le biblioteche che sono molto apprezzate in tutto il settore sono generalmente accettabili (come Boost per C ++, o jQuery per Javascript) - ma sono ancora meno desiderabili rispetto alla Libreria standard perché sono > do tendono ad essere meno stabili rispetto alle 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 in genere raccomando di evitarle nel codice di produzione, a meno che non si abbia familiarità con il codice sorgente per mantenerle da soli.

Quindi è davvero tutto un atto di equilibrio. Ma il punto è che basta dire ciecamente "Il riutilizzo del codice è buono! Reinventare la ruota male!" è un atteggiamento pericoloso. I vantaggi derivanti dall'uso del codice di terze parti devono essere valutati rispetto agli svantaggi dell'introduzione delle dipendenze.

Un motivo utile per reinventare la ruota è a scopo di apprendimento, ma ti consiglio di farlo nel tuo tempo libero. Man mano che sono disponibili più soluzioni pre-inscatolate 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ù e più volte. MA, per questo motivo, puoi affinare le tue capacità e imparare molto cercando di ri-implementare una soluzione da solo. Semplicemente non necessariamente per uso produttivo.

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

A proposito, se si sceglie di implementare il proprio, evitare di farlo per la crittografia o altre funzionalità relative alla sicurezza. Sono già disponibili (e testati) gli strumenti necessari per questo, e in questo giorno ed età, è molto rischioso per i propri. Questo non vale mai la pena, ed è spaventoso che io senta ancora parlare di squadre che fanno questo.

Se la gente non reinventasse le ruote, il mondo sarebbe pieno di queste ..

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 ..

Ci sono due opzioni: o reinventare la ruota OPPURE usare Colorama. Ecco come si presenterebbe ciascuna opzione:

Uso di Colorama

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

Reinventare la ruota

• Comprendi come alcuni programmi sono in grado di mostrare il colore
• Impari che i caratteri speciali possono essere usati per colorare su qualsiasi terminale
• Sei in grado di colorare in qualsiasi linguaggio di programmazione che potresti utilizzare in futuro
• Il tuo progetto ha meno probabilità di rompere

Come vedi, tutto dipende 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 invece stai correndo su una scadenza o se provi a implementare una soluzione enorme e già esiste, allora stai meglio usando quello che c'è.

Esistono due tipi di efficienza: elaborazione / velocità (ovvero la velocità con cui viene eseguita) che può corrispondere e velocità di sviluppo che quasi certamente non lo sarà. Questa è la prima ragione: per qualsiasi problema di ragionevole complessità in cui sono disponibili soluzioni esistenti, sarà quasi certamente più veloce per ricercare e implementare una libreria esistente piuttosto che per codificare il proprio .

La seconda ragione è che la libreria esistente (supponendo che sia matura) è testata e ha dimostrato di funzionare - probabilmente in una gamma di scenari molto più ampia di quella di uno sviluppatore e un team di test sarà in grado di metti una routine appena scritta e questo viene a zero sforzo.

In terzo luogo, è molto più semplice da supportare. Qualcun altro lo supporta e lo migliora (chi ha scritto la libreria / componente), ma è molto più probabile che altri sviluppatori lo conoscano e siano in grado di capire e mantenere il codice andando avanti , tutto ciò riduce al minimo i costi in corso.

E tutto ciò presuppone l'equivalenza funzionale, che normalmente non è il caso. Spesso le librerie offrono funzionalità che potresti trovare utili ma che non potrebbero mai giustificare la creazione, tutte disponibili all'improvviso gratuitamente.

Ci sono motivi per lanciare il tuo - in gran parte dove vuoi fare qualcosa che la funzione incorporata non può fare e dove c'è un vero vantaggio da guadagnare o dove le opzioni prontamente disponibili non sono mature - ma sono meno comuni di quanto molti sviluppatori vorrebbero far credere.

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

Naturalmente reinventare la ruota su un capriccio, per ignoranza e arroganza può essere una brutta cosa, ma IMHO il pendolo è oscillato troppo lontano. C'è un enorme vantaggio nell'avere una ruota che esattamente quello che vuoi e nient'altro .

Spesso quando guardo una ruota esistente, o fa molto più del necessario, soffre dell'effetto sulla piattaforma interna, ed è quindi inutilmente complesso, oppure mancano alcune funzionalità chiave di cui ho bisogno e che sarebbero difficili da implementare in aggiunta a ciò che è già presente.

Inoltre, l'uso di ruote esistenti aggiunge spesso dei limiti al mio progetto che non desidero. Ad esempio:

• La ruota esistente richiede un linguaggio e / o uno stile di programmazione diversi da quelli che altrimenti preferirei usare.
• La ruota esistente funziona solo con la versione legacy di un linguaggio (ad esempio, Python 2 invece di Python 3).
• Laddove ci sono dei compromessi tra efficienza, flessibilità e semplicità, la ruota esistente compie scelte non ottimali per il mio caso d'uso. (Sono stato conosciuto per reinventare anche funzionalità dalle librerie che originariamente mi scrivevo in questi casi, di solito è perché ho scritto la versione della libreria della funzione per essere generica e ragionevolmente efficiente, quando attualmente ho bisogno di qualcosa che sia molto veloce nel mio specifico caso.)
• La ruota esistente ha tonnellate di cruft legacy che è totalmente inutile nel caso del nuovo codice, ma rende comunque la vita difficile (ad esempio, una libreria Java che uso mi costringe a usare le sue classi di crappy contenitore perché è stata scritta prima dei generici, eccetera.).
• 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 per me è conveniente avere un grafico diretto rappresentato da oggetti nodo e riferimenti ma la ruota esistente usa una matrice di adiacenza o viceversa. Forse è conveniente per me disporre i miei dati in ordine di colonna principale, ma il la ruota esistente insiste sulla riga maggiore o viceversa.)
• La libreria aggiunge una dipendenza massiccia e fragile che sarebbe un grosso problema per essere installata 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 semplicemente la funzionalità che desidero in una nuova libreria più piccola o semplicemente copia / incolla se la libreria è open source e il codebase lo rende abbastanza semplice. (L'ho fatto anche con librerie relativamente grandi che ho scritto da solo, non solo quelle di altre persone.)
• La ruota esistente tenta di essere pedanticamente compatibile con alcuni standard che sono sia scomodi e irrilevanti per il mio caso d'uso.

Spesso uso il mio perché l'ho creato prima di scoprire quello preesistente e sono troppo pigro per trovare e sostituire ogni istanza. Inoltre, capisco perfettamente il mio metodo mentre non riesco a capire quello preesistente. E infine, poiché non comprendo pienamente quello preesistente, non posso verificare che faccia assolutamente tutto ciò che fa il mio attuale.

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

Infatti, un'app web asp che è 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 qualche anno fa quando stavo per la prima volta ad imparare su asp.net e non conoscevo i datagrids. Ho paura del codice perché non ho idea di cosa stavo facendo allora, ma funziona, è preciso, è facile da modificare, non si arresta e gli utenti lo adorano

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

Attualmente lavoro per un sacco di cheapskates.

Quando viene presa la decisione tra "costruire o comprare", invece di prendere una decisione razionale basata sull'economia, i gestori hanno scelto 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 esce dal budget, il che si contrappone ai bonus di fine anno male gestiti. Il tempo dei programmatori è gratuito e quindi non conta sui bonus di fine anno (con l'ulteriore vantaggio di dinging i programmatori per non aver fatto tutto "in tempo"), quindi una ruota reinventata è una ruota libera .

In un'azienda razionale, il costo rispetto ai vantaggi delle ruote di acquisto di altri rispetto a reinventare le proprie ruote si baserebbe sui costi a breve ea lungo termine, così come i costi di opportunità persi perché non si possono fare nuovi widget mentre uno sta reinventando le ruote. Ogni giorno che passi a reinventare la ruota è un altro giorno in cui non puoi scrivere qualcosa di nuovo.

Presentazione costruire o comprare
Articolo su build vs buy .

If I see someone is clearly reinventing the wheel by building their own method of something that is already built into the language/framework. First, for arguments sake, lets assume that their method is just as efficient as the built in method. Also the developer, aware of the built in method, prefers his own method.

Why should he use the built in one over his own?

La versione built-in avrà molte più persone che ci sbattono sopra, trovando e sistemando più bug di quanti il tuo codice homebrew possa mai avere.

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

Il fatto di reinventare la ruota è che a volte non esiste una ruota standard standard che faccia ciò di cui hai bisogno. Ci sono molte buone ruote là fuori, in un sacco di dimensioni, colori, materiali e modi di costruzione. Ma alcuni giorni devi solo avere una ruota veramente leggera che sia in alluminio anodizzato verde, e nessuno ne fa uno. In tal caso, devi creare il tuo.

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

La cosa più importante è sapere QUANDO creare il tuo. Devi avere una buona idea di cosa possono fare le parti standard e cosa non possono, 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 un sacco di tempo per reinventare.
• Ci vuole ancora più tempo per documentare ciò che hai inventato.
• Non puoi assumere persone che già comprendano ciò che hai inventato.
• È fin troppo facile reinventare qualcosa di grave, causando costi continui per i problemi causati dal cattivo design.
• Il nuovo codice indica nuovi bug. Il vecchio codice di solito ha già eliminato la maggior parte dei bug e potrebbe presentare 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 della tendenza a "buttare via il vecchio codice e ricominciare da capo" sulla base del fatto che molti dei vecchi cruft che non capisci sono in realtà bugfix essenziali. C'è una storia ammonitrice su Netscape, IIRC.

I vantaggi possono essere ...

• La possibilità di aggiungere funzionalità che le librerie esistenti non hanno. Ad esempio, ho dei contenitori che "mantengono" le loro istanze di iteratore / cursore. Inserimenti e cancellazioni non invalidano gli iteratori. Un iteratore che punta in un vettore continuerà a puntare allo stesso oggetto (non lo stesso indice) indipendentemente dagli inserimenti e dalle eliminazioni precedenti nel vettore. Semplicemente non puoi farlo con i contenitori standard di C ++.
• 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 riprogettare l'API in un modo che significa che devi riscrivere metà della tua applicazione.
• Comprensione completa - l'hai progettata in questo modo, quindi spero che tu comprenda pienamente come e perché l'hai fatto.
• EDIT Puoi imparare le lezioni da altre librerie senza essere catturati nelle stesse trappole essendo selettivi su come li imiti.

Una cosa: usare una libreria di terze parti può contare come reinventare la ruota. Se hai già la tua libreria antica, ben utilizzata e ben testata, pensa attentamente prima di scartarla per utilizzare invece una libreria di terze parti. Potrebbe essere una buona idea a lungo termine - ma ci può essere un'enorme quantità di lavoro e un sacco di brutte sorprese (da sottili differenze semantiche tra le librerie) prima di arrivare. Ad esempio, considera l'effetto di passare da un contenitore personale a uno di libreria standard. Una traduzione ingenua del codice chiamante non consentirebbe al fatto che i contenitori delle librerie standard non mantengano i loro iteratori. Casi in cui ho salvato un iteratore per un secondo momento poiché un "segnalibro" non può essere implementato utilizzando una semplice traduzione - Avrei bisogno di qualche mezzo alternativo non banale per indicare le posizioni dei segnalibri.

Se c'è un componente funzionante che fa ciò che ti serve allora perché passare il tempo a scrivere e fare il debug della tua versione? Allo stesso modo, se hai già scritto codice per soddisfare una funzione simile in precedenza, perché riscriverlo?

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

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

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

La mia regola pratica personale:

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

Essere "cattivo" o anche "cattivo" è una parola piuttosto strong.

Come sempre, ci sono dei motivi per scegliere un'implementazione personale rispetto a uno integrato. Nei vecchi tempi un programma C poteva incontrare bug nella libreria di runtime e quindi semplicemente deve fornire la propria implementazione.

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

link

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

Se usi la ricerca binaria incorporata, hai risparmiato tempo e denaro facendo in modo che Sun stia cercando, risolvendo e distribuendo questo bugfix. Puoi sfruttare il loro lavoro semplicemente dicendo "hai bisogno almeno di Java 6 aggiornamento 10".

Se usi la tua implementazione - che molto probabilmente contiene anche questo errore - devi prima che il bug si manifesti. Dato che questo particolare si mostra solo su set di dati LARGE, è destinato a verificarsi in produzione da qualche parte, il che significa che almeno uno dei tuoi clienti sarà interessato e molto probabilmente perdere soldi veri mentre trovi, correggi e distribuisci il bugfix.

Quindi, è perfettamente valido preferire la propria implementazione, ma la ragione è meglio essere veramente buoni, in quanto è destinata ad essere più costosa di sfruttare il lavoro degli altri.

Recentemente ha bloggato i miei pensieri su questo argomento. Per riassumere:

1. È quasi sempre il male da costruire il tuo, soprattutto vero se è una funzione integrata nel linguaggio. Ma se stai valutando un quadro immaturo / discutibilmente mantenuto / mal documentato che hai trovato su Internet contro la possibilità di scrivere il tuo, potrebbe essere un gioco da ragazzi.

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

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

   "Our website broke. It was someone else's fault, and we've logged a bug with its creator. There is nothing we can do about it except wait. We'll keep you updated."

   "Our website broke, and we were able to fix it immediately."

Forse è altrettanto efficiente, ma è altrettanto robusto? Penso che il motivo più convincente per usare una libreria oltre a far girare il proprio è che il framework ha così tante persone che lo usano che possono trovare e correggere rapidamente 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 in quasi tutti i casi d'uso. Non puoi battere quel tipo di test internamente.

Beh, il suo metodo è efficiente quanto il framework sarebbe piuttosto raro perché molti framework hanno ancora bug e nessun framework può darti una soluzione pronta per l'uso. La maggior parte dei programmatori che non riescono a pensare non tenteranno mai di scrivere nulla a livello di struttura; cercheranno solo Google per una soluzione pronta. Ogni programmatore saggio prima vedrà se c'è un framework libero che ha la funzionalità di cui ha bisogno, e quindi scriverà la soluzione da solo se non ci sarà. A volte è troppo difficile spiegare la situazione attuale 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 sceneggiatori reinventano; l'intero framework .Net è stato reinventato per fare ciò che la COM offriva.

Per quanto offensivo possa essere per alcuni, ho sempre ritenuto che questo termine fosse unclever 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 un disonore quando si considerano le pressioni per innovare nel mondo frenetico di oggi. Ripetersi (o ignorare soluzioni adeguate e preesistenti) non è mai saggio, ma in realtà, c'è una ragione per cui non stiamo ancora tutti fissando gli schermi neri pieni di lettere verdi.

Capisco "Se non è rotto non aggiustarlo", anche se suppongo che una frase del genere possa sembrare ignorante per alcuni. Tuttavia, con lo sforzo attuale di reinventare la ruota per le esigenze di viaggi spaziali, corse, spedizioni, ecc., "Non reinventare la ruota" è piuttosto ignorante, e non è affatto intelligente come sembra.

Il mio background consiste nel condurre 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 dovuto anche deviare le persone dalla caccia all'insieme di conigli al di fuori della portata dei loro compiti. Tuttavia, vorrei mai scoraggiare l'innovazione o la creatività e ho visto grandi cose venire dal "re-inventare la ruota".

La mia risposta effettiva alla domanda: ci sono solo due situazioni in cui la reinvenzione della ruota è una brutta cosa:

1. Se non è veramente necessario
2. Se è l'altro a farlo quando puoi

Modifica: Riesco a vedere dai voti bassi che devo aver offeso alcuni. L'unica cosa che vorrei aggiungere è che questa frase è sempre stata una delle mie principali pet-peeve. Capisco che i miei due centesimi potrebbero sembrare piuttosto trollistici, ma non ho intenzione di trollare, provocare incendi o offendere.

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

Diciamo che sto valutando una libreria 'forms-plus', che è appena diventata popolare di recente e aiuta a gestire i moduli. Ha una bella pagina di destinazione, una grafica moderna e moderna, e un -cult- (oops intendo comunità) attorno a lui che giura come rendere le forme di nuovo grandiose. Ma "forme-plus" è un'astrazione in cima alle "forme". "le forme" erano possibili ma difficili da gestire, quindi l'astrazione che rende più facile sta diventando popolare.

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

La valutazione di questo nuovo dispositivo "forms-plus" sarà diversa a seconda dell'esperienza personale. Se non avessi mai creato i moduli prima di allora, "form-plus" sarà molto avvincente perché è più facile iniziare. Il rovescio della medaglia è che se "form-plus" risulta essere un'astrazione che perde, dovrò comunque imparare le "forme". Se costruissi moduli senza "form-plus", allora dovrò prendere in considerazione il tempo che mi serve per imparare un nuovo strumento. Il lato positivo è che conosco già "forme" quindi non ho paura delle astrazioni su di esso. I benefici a breve termine spesso saranno maggiori per i nuovi utenti perché probabilmente non ci sarebbe una nuova libreria se non migliorasse qualcosa. I benefici a lungo termine varieranno ampiamente sulla qualità dell'astrazione, sul tasso di adozione e su altri fattori già discussi in altre risposte.

Dopo aver valutato attentamente i benefici e i negativi dell'uso di una nuova astrazione "forme-plus" vs utilizzando "forme" di osso nudo, prendo una decisione. La decisione è strongmente basata sulle mie esperienze personali e persone diverse prenderanno decisioni diverse. Avrei potuto scegliere di usare "forme" a osso nudo. Forse più tardi nel tempo le forme - più avevano guadagnato più movimento dietro e diventando uno standard de facto. E forse la mia implementazione col passare del tempo si è fatta pelosa e ha iniziato a coprire molto le forme - e adesso sta facendo. Le persone che verranno in questo momento saranno attratte dal criticare il fatto che sono entusiasta di reinventare la ruota e che avrei dovuto usare la libreria esistente. Ma è anche possibile che nel momento in cui dovevo prendere una decisione su "forme-plus" c'erano anche molte altre alternative alle "forme-plus", la maggior parte di questi progetti ormai morti, e forse ho guadagnato non scegliendo il torto uno.

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

Ho scritto un piccolo articolo su questo - link

Nella mia esperienza, la re-invenzione è stata davvero grande, anche se molto lunga e noiosa. Direi che se non conoscete esattamente i modelli di programmazione che userete, scriveteli voi stessi (se avete tempo ed energia). Questo ti insegnerà cosa significano esattamente quei modelli di programmazione e alla fine diventerai un programmatore migliore. Ovviamente, se stai lavorando per un cliente e hai bisogno di fare qualcosa velocemente, probabilmente vorresti solo fare delle ricerche e trovare il software giusto per te.