Ci sono ragioni concrete per non usare pesantemente le librerie e gli snippet di codice? [chiuso]

Complessivamente sto programmando da circa 8 anni e mi sembra di fare sempre più affidamento su librerie e snippet open source (maledetto GitHub!) Per "portare a termine il lavoro". So che col tempo potrei scrivere la mia implementazione, ma mi piace concentrarmi sul design generale.

È normale (ambiente non aziendale)? Cosa potrebbe andare storto se la mia "programmazione" non è altro che incollare insieme librerie diverse?

So "non reinventare la ruota" ma cosa succede quando non inventi più una ruota?

Usare le librerie invece di reinventare la ruota: fantastico! Ecco come dovrebbero farlo tutti. Non vieni pagato per fare ciò che è già stato fatto.

Usare i frammenti: finché capisci cosa copi e incolli e finché investi il ​​tempo per renderlo coerente (invece di un patchwork di stili e approcci diversi), non c'è nulla di sbagliato in questo.

i bravi programmatori scrivono un buon codice; grandi programmatori rubano ottimo codice.

La codifica è infatti il ​​livello di programmazione più basso. Maggiore è il livello di astrazione che puoi raggiungere, migliore è il programmatore. Scegliere le librerie giuste (non necessariamente quelle open source), collegarle correttamente e mantenere il costrutto è molto più difficile, ma più efficiente e fa risparmiare tempo e denaro, piuttosto che scrivere tutto da soli.

Adoro scrivere le mie librerie. Adoro anche portare a termine i miei progetti in tempo. Penso che nel tempo la maggior parte dei bravi programmatori costruisca una raccolta di bit utili e riutilizzabili. Non ti conosco, ma mi sento molto bene ogni volta che uso una biblioteca che ho scritto cinque anni fa.

Non c'è assolutamente nulla di sbagliato nell'utilizzo del codice della libreria che è stato testato e amato nel tempo. Sai come funziona, puoi contare sulla sua complessità e puoi implementarlo rapidamente.

Detto questo, presumo che tu capisca il codice nella libreria. Suppongo che, se concesso tempo sufficiente, potresti implementare qualcosa di simile qualità.

Conosco alcuni programmatori C davvero bravi che potrebbero implementare la libreria C standard, alcuni dei quali hanno semplicemente un esercizio di apprendimento / affinamento. Alcuni dei più divertenti che ho avuto durante il tempo degli hobby sono stati lavorare nella biblioteca C di HelenOS.

Quindi, non c'è niente di sbagliato nell'usare il codice della libreria, purché tu sia curioso e impari. E 'ovvio che si dovrebbe non utilizza il codice che non si capisce, a meno che il vostro uso di esso è uno sforzo per capire come funziona.

Ne vado uno migliore di altri in questa domanda: non penso nemmeno che lo sviluppatore "client" di una libreria debba "capire" il codice in quella libreria.

Sono uno sviluppatore di iPhone (rispetto ad alcuni) relativamente nuovo. Ci sono MOLTE biblioteche che uso ogni giorno che non avrei mai potuto generare da solo, e il cui codice è decisamente eccessivo. Non importa minimamente FORNITO:

1) Comprendo appieno l'interfaccia di quelle librerie (sono un ninja ASIHTTPRequest!)
2) Sto raccogliendo librerie che sono in generale, di ampio uso, quindi posso essere sicuro che sono state ben esaminate ed esplorate per problemi (es: ASIHTTP, la libreria JSON di Stig Brautaset, la libreria obj-c di Facebook, ecc.)
3) In mancanza del n. 2, è abbastanza semplice che potrei farcela e trovare / riparare / personalizzare tutto ciò che ha bisogno di trovare / riparare / personalizzare .

Quel numero 2 sarà la parte controversa di questo, sto scommettendo. Il fatto è che mi affido alla comunità open source, una comunità di sviluppatori che è sicuramente più esperta e molto probabilmente più intelligente di me. Ma questo è l'intero punto dell'open source. Quindi, eccoti.

Vorrei lanciare un avviso per l'utilizzo delle librerie. Come utente frequente di biblioteche scientifiche in Perl an R (e alcune in Java), spesso dovevo hackerare una libreria per evitare orribili spese generali. L'uso delle librerie è fantastico, ma sempre più librerie dipendono esse stesse da altre librerie, che chiama una terza libreria che utilizza la libreria standard per svolgere un'attività piuttosto comune. E ogni fase del processo richiede alcuni controlli di input e output. Molti di questi controlli sono completamente ridondanti, ma pesano comunque sull'applicazione. E se usato in un ciclo, può iniziare a pesare abbastanza pesantemente.

Oltre a ciò, non puoi essere sicuro che le librerie mantengano sempre la retrocompatibilità o non contengano bug. In effetti, tutte le librerie contengono alcuni bug, questa è la natura del codice. Quindi, più dipendi dalle librerie, più potenziali bug inserisci nel tuo codice. E quei bug che non riesci a risolverti così facilmente senza entrare di nuovo nelle librerie.

L'uso delle librerie è una decisione molto intelligente, ma se e solo se si conoscono abbastanza bene le librerie e il loro comportamento.

Lo so, pensare che male e computer siano economici, ma comunque. Non pensare può far male di più.

Di solito, copiare grandi quantità di codice sorgente è una pratica inadeguata. Se il codice è stato sviluppato per un'altra applicazione della tua azienda, dovresti riutilizzarlo estraendolo in una libreria per essere utilizzato da entrambe le applicazioni. Non dovresti copiare il codice. La copia del codice ti costringerà a conservare due copie anziché una copia comune.

Il riutilizzo del codice è un'ottima idea. Riduce la ridondanza e promuove la manutenibilità.

Il titolo suggerisce che stai usando il codice come libreria, ma il testo della tua domanda implica che potresti copiare il codice sorgente in un nuovo progetto. Continuerei a usare il codice di altri sviluppatori come libreria il più possibile.

C'è un problema se il codice è errato o in qualche modo rotto o basato su un modello che non si adatta molto bene alla tua applicazione. In tal caso, potrebbe essere più semplice eliminare tutto o parte del codice e ricominciare da capo piuttosto che cercare di capire perché è stato scritto in un determinato modo. Tieni l'altro codice in giro per riferimento, però; potresti riscontrare un problema che non sei sicuro di come risolvere. È probabile che l'altro sviluppatore abbia riscontrato lo stesso problema e vale la pena vedere come l'hanno risolto.

Questa è generalmente una buona idea, così a lungo non esistono problemi legali.

Tuttavia, assicurati di dedicare del tempo a capire cosa fa la libreria e come lo fa. Usare una libreria "magica" per prendersi cura di cose che non capisci è un buon modo per farti esplodere una parte di essa perché l'hai usata male e quindi non hai idea di come risolverla.

Il riutilizzo legale del codice non ha quasi aspetti negativi e due enormi vantaggi:

1. Fa il lavoro. Questo è il più importante per lo sviluppo professionale. In definitiva, hai un lavoro ben pagato perché sai come far accadere le cose che potrebbero sconcertare la maggior parte dei non programmatori; il riutilizzo ti consente di raggiungere questo obiettivo più rapidamente, in modo da diventare più prezioso nel tuo lavoro.
2. Impari cose. Questa è la ragione più importante per l'auto-miglioramento. Non c'è modo migliore per migliorare la codifica che leggere un buon codice scritto da altri. Anche il cattivo codice scritto da altri di solito ti insegna qualcosa! E non c'è modo migliore per capire come funziona una libreria, API, lingua o dominio che leggere e migliorare soluzioni già scritte da altri. Entrambe le cose di solito accadono quando riutilizzi il codice esistente, perché nessuna soluzione preesistente farà mai esattamente ciò di cui hai bisogno - e il conseguente armeggiamento con la fonte è da dove proviene l'incremento della conoscenza.

L'uso pesante di librerie e frammenti di codice ti rende un programmatore inadeguato?

Se usi librerie e frammenti di codice in posizioni appropriate, allora "No" non significa che sei un cattivo programmatore. Significa che sei un programmatore intelligente che può applicare la saggezza degli altri in luoghi appropriati.

Tuttavia...

Ci vuole tempo per trovare librerie e frammenti di codice, quindi se non riesci a scrivere codice da solo, e devi passare ore a trovare librerie e frammenti di codice per implementare attività banali, quindi "Sì" , sei un cattivo programmatore.

No. I programmatori dovrebbero usare librerie che sono già disponibili. Non reinventare la ruota. Se hai un metodo migliore, puoi provarlo, altrimenti cosa fa veramente scrivendo lo stesso codice. L'unica cosa è che dovresti sapere qual è il codice (e solo se è importante).

Oltre ai motivi delle altre risposte, non usare il codice (purché sia ​​adatto al tuo problema) può essere considerato non etico perché:

1. Potresti sprecare intenzionalmente il tempo dei tuoi datori di lavoro OPPURE
2. Potresti fornire intenzionalmente un prodotto di qualità inferiore

Tieni presente che entrambi sono difficili da determinare in anticipo.

Inoltre, guarda Non inventato qui , che comunemente indicato come un modello anit.

A scopo di completamento, consentire un contro argomento: http://web.archive.org/web/20150326134617/https://michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-even-worse -sibling-di-non-inventato-qui /

una mentalità che chiamo "Never Invent Here" (NeIH). Con questa mentalità, le risorse esterne sono sopravvalutate e spesso implicitamente fidate, lasciando agli ingegneri più tempo per adattarsi alle stranezze delle risorse standard e meno tempo per la costruzione di risorse proprie.

C'è sempre un equilibrio.

Sto per non usare le librerie a meno che non sia assolutamente necessario. Le dipendenze limitano la portabilità e la durata. Ho 34 anni nello sviluppo del software e vorrei che almeno 1 dei miei programmi durasse più di 3 anni senza essere distrutto dall'erosione (cambiamento).

COM (Component Object Model), la risposta 17 anni fa, in teoria eccezionale, in pratica componenti discutibili, riutilizzabili, non proprio, userò solo i componenti di base e solo se devo.

Le API e gli SDK non sono molto utili. Se analizzo il numero di righe di codice che uso effettivamente da una libreria, il tempo che dedico a farle funzionare piuttosto che a scriverle, penso che sia un lavaggio. Ho smesso di usare SDK completamente l'overhead è estremo.

Strutture: Zend, Silverlight, WCF, .NET, i sistemi a strati, sì, possono accelerare lo sviluppo iniziale, ma quando raggiungo i loro limiti, il tempo che dedico a riparare le crepe, non vale la pena. Quanti anni hanno e sono impermeabili all'erosione?

Sono passato a JavaScript e HTML con solo le mie librerie. Ho eliminato JavaScript utilizzando solo i tipi di istruzione più comuni. Spero tra 10 anni di poter scrivere qualcosa che duri.

Tutto dipende. Se stai programmando un gioco, allora è necessario usare una libreria (es. Allegro) ma non puoi davvero essere considerato un programmatore se stai copiando / rubando / prendendo in prestito (qualunque cosa) il codice di altre persone. Dico di non reinventare la ruota ma a un punto ragionevole. Non creare l'intero programma di frammenti che altre persone hanno scritto. Siediti al tuo computer e fallo da solo ... smetti di rubare il codice. Le persone sono diventate troppo pigre in questi giorni e semplicemente copia e incolla.