Le librerie scritte per soddisfare un gruppo ampio e diversificato di utenti devono essere progettate in modo diverso rispetto al codice specifico del progetto. Devi renderli più robusti, gestire una gamma più ampia di casi limite e fornire funzionalità e flessibilità sufficienti per renderli utili a tutti.
Devi decidere se la maggior parte del codice è valida o meno. Se è una libreria ben mantenuta, ha una buona documentazione ed è intuitiva, non ti interessa il codice di massa. E sì, odio ammetterlo, ma la popolarità conta, se non altro perché puoi trovare una cultura di persone che già conoscono e capiscono la biblioteca.
La verità è che, mentre probabilmente uso molte librerie senza nemmeno pensarci (specialmente il framework .NET, che ha un notevole volume di codice ma anche una vasta gamma di funzionalità), non ho quasi mai la necessità di mantenere quelle librerie in il livello di codice; gli altri lo fanno per me. Dal momento che in genere non programma i dispositivi embedded (che hanno limiti significativi di memoria e processore), non penso davvero molto alla maggior parte del codice.
Ho usato Newtonsoft.JSON per anni. Ha un'API semplice e intuitiva, è molto robusto e funziona. Non ho idea di quanto sia grande, ma sono sicuro che la sua dimensione non è banale. Le sue dimensioni non sono mai state un problema per me, quindi non l'ho mai considerato un fattore.
Detto questo, in un numero significativo di casi dopo aver valutato tutte le alternative, scelgo il codice personalizzato sulle librerie, perché ho solo bisogno di fare qualcosa; Controllo il codice, le sue caratteristiche di prestazione, ecc., E la semplicità del fare supera il costo del marshalling di una gigantesca libreria. Sono strongmente favorevole ai sistemi semplici; a parità di altre condizioni, meno codice è sempre migliore. Ma anche a me non piace reinventare cose che sono già state fatte molto bene da altre persone, e c'è solo così tanto codice che posso scrivere come una sola persona.
Alcune tecnologie sono basate su un ecosistema di librerie, quindi se scegli una di queste tecnologie, stai acquistando una filosofia di libreria. Non mi sorprende affatto se Aurelia utilizza due librerie cento di vario tipo. Nel mondo finanziario, chiamiamo questo leverage; sei letteralmente in piedi sulle spalle dei giganti.
Al contrario, abbiamo visto tutti progetti di "casa delle carte" in cui risme di codice che non fa molto se non fornire struttura si alza in piedi come un'elaborata cattedrale di cristallo. È un codice interessante da guardare, ma non sono convinto che gran parte di quel codice porti il suo peso, nel senso che i suoi benefici superano i costi. Una libreria ben scritta lo eviterà.
Alcuni ecosistemi come le librerie Javascript hanno una cultura economica; le librerie scritte in questo spazio tendono ad essere piccole perché sono soggette a vincoli logistici (ad esempio larghezza di banda del browser).
Alcune biblioteche sono "supponenti", nel senso che è necessario acquistare nella filosofia dello scrittore di biblioteche l'uso efficace della biblioteca. Caliburn Micro è un esempio di tale libreria; così è Angolare e Knockout. Altre librerie sono di natura più generica. Genericity tende a generare più codice.
In un'era di dispositivi di archiviazione multi-terabyte, memoria multi-gigabyte e Internet a 15 Mbit +, ottenere le funzionalità che desideri in una libreria di cui ti puoi fidare è probabilmente più importante della dimensione del codice.