Ci sono motivi concreti per non usare pesantemente le librerie e i frammenti di codice? [chiuso]

Usare le librerie invece di reinventare la ruota: fantastico! È così che tutti dovrebbero farlo. Non sei pagato per fare ciò che è già stato fatto.

Uso di frammenti: finché capisci cosa copia-incolla e finché investi il tempo necessario per renderlo tutto coerente (invece di un patchwork di stili e approcci diversi), non c'è niente di sbagliato in questo.

good programmers write good code; great programmers steal great code.

La codifica è di fatto il livello più basso di programmazione. Il livello più alto di astrazione che puoi ottenere, il programmatore migliore sei. Scegliere le librerie giuste (non necessariamente quelle open-source), correttamente collegarle insieme e mantenere il costrutto è molto più difficile ma più efficiente e risparmiare tempo e denaro, piuttosto che scrivere tutto da solo.

Amo scrivere le mie librerie. Mi piace anche che i miei progetti vengano eseguiti in tempo. Credo che nel tempo, la maggior parte i bravi programmatori costruiscano una raccolta di bit utili e riutilizzabili. Non so voi, ma ho una sensazione fantastica ogni volta che uso una libreria che ho scritto cinque anni fa.

C'è assolutamente niente sbagliato nell'usare il 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 avessi tempo sufficiente, potresti implementare qualcosa di simile qualità.

Conosco alcuni programmatori C molto bravi che potrebbero implementare la libreria C standard, alcuni dei quali hanno semplicemente un esercizio di apprendimento / affilatura. Alcuni dei momenti più divertenti che ho avuto durante il passatempo lavoravano sulla libreria C di HelenOS.

Quindi, non c'è niente di sbagliato nell'usare il codice della biblioteca, a patto che continui a essere curioso e ad imparare. Va da sé che dovresti non usare un codice che non capisci, a meno che il tuo uso non sia uno sforzo per capire come funziona.

Ne parlerò meglio di altri in questa domanda: non penso nemmeno che lo sviluppatore "client" di una libreria debba "capire" il codice in quella libreria.

Sono uno (relativamente ad alcuni) relativamente nuovo sviluppatore di iPhone. Ci sono un sacco di librerie che uso ogni giorno che non avrei mai potuto generare da solo, e il cui codice è davvero superfluo. Non importa nel minimo FORNITO:

1) Comprendo appieno l'interfaccia di queste librerie (sono un ninja ASIHTTPRequest!)
2) Sto raccogliendo librerie che sono in generale, ad ampio uso, quindi posso essere sicuro che siano state affrontate e analizzate per problemi (ad esempio: ASIHTTP, libreria JSON di Stig Brautaset, libreria obj-c di Facebook, ecc.)
3) In mancanza di # 2, è abbastanza semplice che potrebbe sceglierlo attraverso di esso e trovare / correggere / personalizzare qualsiasi cosa abbia bisogno di trovare / correggere / personalizzare.

Quella # 2 sarà la parte più controversa di questo, scommetto. 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, ecco qua.

Vorrei lanciare un avvertimento per usare le librerie. Come utente frequente di librerie scientifiche in Perl e R (e alcune in Java), ho dovuto spesso hackerare in una libreria per evitare costi orribili. L'utilizzo delle librerie è ottimo, ma sempre più biblioteche dipendono da altre librerie, il 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. Parecchi di questi controlli sono completamente ridondanti, ma pesano comunque sull'applicazione. E se usato in un ciclo, può iniziare a pesare molto pesantemente.

Accanto a questo, non puoi essere sicuro che le librerie mantengano sempre la compatibilità retroattiva, o non contengano bug. In effetti, tutte le librerie contengono alcuni bug, questa è la natura del codice. Quindi, più dipendi dalle biblioteche, più potenziali bug inserisci nel tuo codice. E quei bug che non riesci a risolvere da soli così facilmente senza ricorrere nuovamente alle librerie.

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

Lo so, pensare male e computer sono economici, ma ancora. Non pensare può fare più male.

Di solito, copiare grandi quantità di codice sorgente è una cattiva pratica. Se il codice è stato sviluppato per un'altra applicazione nella tua azienda, dovresti riutilizzare il codice estraendolo in una libreria per essere utilizzato da entrambe le applicazioni. Non dovresti copiare il codice. La copia del codice ti costringerà a mantenere due copie invece di 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. Mi limiterei a utilizzare il codice di altri sviluppatori come una libreria il più possibile.

C'è un problema se il codice è cattivo o in qualche modo rotto o basato su un modello che non si adatta alla tua applicazione molto bene. In tal caso, potrebbe essere più semplice di cancellare parte o tutto il codice e iniziare da zero piuttosto che cercare di capire perché è stato scritto in un determinato modo. Mantenere l'altro codice in giro per riferimento, però; potresti incontrare un problema che non sei sicuro di come risolvere. Probabilmente l'altro sviluppatore ha probabilmente riscontrato lo stesso problema, e vale la pena di vedere come lo hanno risolto.

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

Tuttavia, assicurati di avere il tempo di capire cosa fa la libreria e come funziona. Usare una libreria "magica" per occuparsi di cose che non capisci è un buon modo per far esplodere una parte di essa perché l'hai usata in modo errato, e quindi non hai idea di come risolverlo.

Il codice che rientra legalmente non ha quasi aspetti negativi e due enormi svantaggi:

1. Finisce 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 bloccare la maggior parte dei non programmatori; il riutilizzo ti consente di raggiungere quell'obiettivo più velocemente, in modo che tu diventi più prezioso nel tuo lavoro.
2. Impari cose. Questa è la ragione più importante per l'auto-miglioramento. Non esiste un modo migliore per migliorare la codifica piuttosto che leggere un buon codice scritto da altri. Anche il brutto codice scritto da altri ti insegna di solito qualcosa! E non c'è modo migliore per capire come funziona una libreria, API, lingua o dominio piuttosto che leggere e migliorare soluzioni già scritte da altri. Entrambe le cose accadono di solito quando riutilizzate il codice esistente, perché nessuna soluzione preesistente farà mai abbastanza ciò di cui avete bisogno - e il conseguente armeggiare con la fonte è da dove proviene l'impulso alla conoscenza.

Does heavy library and code snippet usage make you a bad programmer?

Se utilizzi le librerie e i frammenti di codice nelle posizioni appropriate, quindi "No" , non significa che sei un programmatore scadente. Significa che sei un programmatore intelligente che può applicare la saggezza degli altri nei luoghi appropriati.

Tuttavia ...

Ci vuole tempo per trovare librerie e frammenti di codice, quindi se non puoi scrivere codice da solo, e hai bisogno di passare ore per trovare librerie e snippet di codice per implementare compiti banali, allora "Sì" , sei un cattivo programmatore.

No. I programmatori dovrebbero usare le librerie che sono già disponibili. Non reinventare la ruota. Se hai un metodo migliore, puoi farlo, altrimenti cosa fa veramente nello scrivere 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 perdere intenzionalmente il tempo del tuo datore di lavoro O
2. potresti fornire intenzionalmente un prodotto inferiore

Ricorda, entrambi sono difficili da determinare in anticipo.

Inoltre, guarda Non inventato qui , che comunemente viene chiamato anit-pattern.

Per scopi di completamento, consenti un argomento contatore: link

a mentality that I call "Never Invent Here" (NeIH). With that mentality, external assets are overvalued and often implicitly trusted, leaving engineers to spend more time adapting to the quirks of off-the-shelf assets, and less time building assets of their own.

C'è sempre un equilibrio.

Sono abituato a non usare le librerie se non assolutamente necessario. Le dipendenze limitano la portabilità e la durata della vita. Ho 34 anni nello sviluppo di 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 grandi, in pratica discutibili, le componenti riutilizzabili non proprio, userò solo le componenti di base e solo se necessario.

API e SDK non sono molto utili. Se analizzo il numero di righe di codice che uso effettivamente da una libreria, il tempo che trascorro facendole funzionare e scrivendole, penso che sia un lavaggio. Smetto di usare gli SDK completamente il sovraccarico è estremo.

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

Sono andato su JavaScript e HTML con solo le mie librerie. Ho rimosso JavaScript in modo errato utilizzando solo i tipi di istruzione più comuni. Spero che tra 10 anni scriverò qualcosa che durerà.

Tutto dipende. Se stai codificando un gioco, allora fa da usare una libreria (ad esempio Allegro) ma non puoi davvero essere considerato un programmatore se stai copiando / rubando / prendendo in prestito (qualunque) il codice degli altri. Dico di non reinventare la ruota ma a un punto ragionevole. Non creare l'intero programma di frammenti scritti da altre persone. Sedersi al computer e farlo da soli ... smettere di rubare il codice. Al giorno d'oggi le persone sono diventate troppo pigre e basta copiare e incollare.