Dovresti usare una libreria quando puoi fare l'attività senza di essa? [chiuso]

Come ingegnere, forse è appropriato considerarlo come un problema di ottimizzazione. Ovviamente dobbiamo avere un obiettivo di ottimizzazione. Una cosa comune in questo tipo di situazione sarebbe di ridurre al minimo costo totale di proprietà .

Se ritieni che l'aggiunta del componente di terze parti consentirà di risparmiare sui costi a lungo termine, dovresti utilizzarla. Se non lo fai, non dovresti. Assicurati di considerare il costo della manutenzione in corso (ad esempio, quando viene rilasciata una nuova versione di O / S, o viene rilevato un difetto di sicurezza o vengono rilasciate alcune nuove specifiche W3C).

Per molti problemi banali, sarà un costo inferiore per far crescere la tua, ma per problemi moderatamente complessi al di fuori della competenza principale della tua organizzazione, spesso avrà senso rivolgersi a terzi.

Ci sono anche altri obiettivi da considerare (ad es. rischio) ma il TCO è il più grande.

Bill Gates, una volta famoso ha detto:

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

Questa citazione viene in mente perché lo stesso potrebbe essere detto per il numero di librerie. Di regola, non utilizzo le librerie a meno che:

1. Non c'è altro modo per farlo. Fare a meno non sarebbe più economicamente fattibile per produrre il prodotto in tempo e budget.
2. Mi farebbe risparmiare un bel po 'di tempo in quanto richiederei molte delle funzionalità di detta libreria
3. La biblioteca è ben utilizzata e tutti i potenziali problemi che potrei avere sarebbero ben documentati.

Idealmente tutte le tre condizioni sono soddisfatte, ma mi accontento di due. In conclusione, non dovresti aggiungere una libreria al tuo programma a meno che non serva a uno scopo. Se devi chiedere qual è lo scopo, probabilmente non dovresti aggiungerlo al tuo programma. Il codice qualità del tuo programma è quindi vantaggioso perché richiama elegantemente ciascuna libreria senza essere appesantito dalla necessità di riscrivere necessariamente le librerie all'interno del tuo programma.

Buona fortuna!

(Nota: la domanda originale era: il numero di librerie migliora la qualità del codice?)

Probabilmente puoi risponderti da solo: No, ovviamente il semplice fatto di usare le librerie non migliora il tuo codice. Se lo facesse, sarebbe facile scrivere un ottimo codice per tutto senza alcuno sforzo.

Ciò che le persone intendono quando raccomandano il riutilizzo su roll-your-own è che il codice in una libreria ben nota è probabilmente più corretto, efficiente e / o utilizzabile rispetto a quello che verrebbe da te, semplicemente perché gli autori hanno speso molto più tempo su una particolare area di funzionalità di quanto tu possa permettersi (con la tua scadenza per l'intero progetto).

Ma questa è solo una tendenza, non una legge. Certamente ci possono essere delle librerie che non sono così utili da usare come sarebbe il tuo roll-your-own. Spesso questo accade quando la libreria effettivamente fa molto più di quello che ti serve, e lo fa in un modo che ti costringerebbe ad adattare il tuo codice base alle loro convenzioni molto più di quanto sia ragionevole. Sembra che questo sia esattamente ciò che hai trovato in questa istanza.

Mentre usi le librerie giuste puoi risparmiare un sacco di lavoro, c'è anche un sacco di costi nascosti:

• Le librerie devono essere tenute aggiornate. È necessario verificare regolarmente se hanno aggiornamenti (che potrebbero essere rilevanti per la sicurezza!) E applicarli. Ogni aggiornamento di libreria potrebbe potenzialmente rompere qualcosa nella tua applicazione. Ciò significa che è necessario eseguire un test di integrazione completo in seguito. Quindi ogni libreria dal quale dipende il tuo progetto aumenta i costi di manutenzione a lungo termine.
• Alcune librerie Javascript sono così potenti e utilizzano modelli unici che le persone iniziano a percepire come aree tecniche separate di competenza. Quindi ogni libreria aggiuntiva che aggiungi potrebbe spaventare gli sviluppatori che non si sentono sicuri di modificare il codice che si basa su un framework con cui non hanno familiarità. Assumere nuovi programmatori di manutenzione che abbiano familiarità con tutte le librerie che usi potrebbero diventare impegnativi.
• L'aggiunta di una libreria al tuo sito web aumenta i tempi di caricamento, perché l'utente deve caricare l'intera libreria, anche se ne usi solo una piccola parte. Alcune librerie popolari ti permettono di scaricare build personalizzate con solo la funzionalità di cui hai bisogno, ma anche in questo caso solitamente includerai ancora un sacco di codice che non funzionerà mai (o ancora peggio: il codice che fa esegue, ma non fa nulla di utile, perché prepara solo strutture dati per funzionalità che non usi).

Quindi, prima di aggiungere un'altra dipendenza al tuo progetto per includere qualcosa che potresti anche scrivere da solo, esegui un'analisi costi / benefici.

Questo non deve essere una decisione binaria: utilizzare solo una libreria OSS o programmare una nuova soluzione da zero. Un'altra opzione potrebbe essere quella di riutilizzare parti della libreria, se la licenza lo consente.

Ad esempio, nel mio campo (software numerico) una libreria può disporre di moduli di core fine e alcuni moduli specializzati di cui sono soddisfatto solo all'80%. Quindi userei i moduli principali e scriverei un wrapper per i moduli specializzati. Oppure potrei sviluppare i miei moduli specializzati utilizzando il design e il codice dei moduli OSS. I bit più difficili e algoritmici di solito vengono riutilizzati da quelli, con solo il codice dell'armatura modificato. Potrei anche ripulire parte del codice originale. Ciò ha dimostrato una buona esperienza di apprendimento e un risparmio di tempo, rispetto allo sviluppo da zero.

Se qualcuno ha già fatto il lavoro per te, ovviamente dovresti usarlo.

L'eccezione alla regola è javascript. Dove avranno importato una dozzina di altre librerie (ovviamente versioni obsolete) per aggiungere le funzionalità linguistiche che vogliono usare e allora hanno fatto il lavoro per te.

Scegli la tua struttura e rimani al suo interno. Se la libreria funziona con il tuo framework o semplicemente js, bene. Ma se ha bisogno di un quadro diverso, cerca un'altra opzione.

Le librerie e quando usarle è una decisione complicata.

Da un lato ci sono cose ben collaudate, quasi standard (nel mio campo, FFTW per esempio rientra in questa categoria, o qualcosa come libsndfile), che sono generalmente riconosciute solo per funzionare, e sono state cose standard per l'ultimo 20 anni che tutti usano.

D'altra parte hai roba casuale da github, senza suite di test e solo circa 1 manutentore, generalmente perché preoccuparti?

Il test dell'acido per me è in primo luogo che la libreria si adatta alla mia architettura (a volte, se sai che vuoi usare una determinata libreria finisci per disegnare intorno a quella), e penso che finirò per fare il debug di qualcuno codice libreria Elses? Un buon proxy per la seconda domanda è "Esiste una suite di test automatizzata e come funziona la documentazione?".

Un po 'di debug non è un grosso problema, ma a quel punto il codice della libreria inizia a contare contro la mia dimensione del codice da una prospettiva di manutenzione (Altro se le mie correzioni non possono essere spinte a monte per qualche motivo).

Distinguerei anche tra le librerie e i framework, per quanto la distinzione a volte non sia così netta, i framework nel mio (piccolo core, DSP heavy) tendono ad essere un rompicoglioni, specialmente se stai provando a unire più di uno o fare qualcosa leggermente al di fuori delle linee, a volte le librerie sono utili. Sono consapevole del fatto che questo si vede in modo molto diverso nella scena del web dev.

Fine del giorno è una decisione che scende al gusto e all'esperienza, e anche l'esperto a volte sceglie male, almeno con una biblioteca, puoi sempre strapparlo e scrivere la tua implementazione se diventa troppo fastidioso .

Decisioni, decisioni ....