Questo potrebbe essere molto soggettivo e dipende dalla tua psicologia e sensibilità, ma le mie librerie di più lunga durata che ho usato per i miei progetti personali e non ho iniziato a odiare nel corso degli anni sono sempre state le mie più piccole, le più isolate (no dipendenze esterne ad altre librerie).
È perché ci vuole solo un'idea stupida o arcaica per confondere la mia intera percezione della biblioteca. Come se potessi avere un codice C perfettamente ragionevole per rasterizzare le forme in una libreria di disegni, eccetto che dipende da una libreria di immagini e matematica che ho scritto negli anni '90 contro le immagini a 16 bit che, in retrospettiva, ora sono completamente shite. Potrei anche avere una libreria di analisi in C ++ con qualche codice di analisi e codice AST decente, tranne che l'ho accoppiato a un flusso di analisi monolitico che, in retrospettiva, era un progetto davvero stupido e poco pratico. Quindi ora l'intera cosa sembra una merda. La maggior parte del mio codice C ++ degli anni '90 è una schifezza totale per me dato che non sapevo come progettare in modo efficace in C ++ allora e facevo cose stupide come usare l'ereditarietà per "estendere" e fornire funzionalità superset formando classi con oltre 100 membri e astrazioni sciocche invece di modellare sottotipi appropriati con interfacce minimaliste. Più del mio codice C è sopravvissuto al mio filtro shite, anche se solo in minima parte. Per lo più sono venuto con una montagna di shite. Le piccole pepite d'oro che ero in grado di individuare erano sempre il codice più disaccoppiato e minimalista con la più grande singolarità di scopo e spesso dipendevano da poco più che da tipi di dati primitivi.
Quindi non voglio nemmeno più preoccuparmi di queste librerie, eccetto forse portare il codice su una nuova libreria che non si preoccupa di quelle e funziona solo contro i raw 32 bit e 128 bit e incorpora invece la matematica vettoriale di dipendere da una lib di matematica esterna per, per esempio, la lib di rasterizzazione. Quindi il codice dura molto più a lungo e mi rende felice. Sono un po 'cinico con le mie opinioni sulle librerie. Tendo a giudicarli dagli anelli più deboli invece che dai collegamenti più forti. Non posso trascurare il male a favore del bene fino a che il male non è completamente eliminato da quella libreria.
Quindi io voto per le biblioteche più piccole e indipendenti perché hanno una probabilità più bassa, almeno per me, di sentirsi come se fossero più tardi. Se lavori in una squadra, voterei ancora di più con standard più forti per mantenere le librerie separate tra loro, dal momento che possono diventare molto veloci con molte mani su di esse a meno che non abbiano uno scopo molto singolare e un obiettivo verso il minimalismo (cercando ragioni per non aggiungere altro invece sempre trovando ragioni per aggiungere altro - non si può odiare ciò che non si aggiunge) ... anche se suonava dalla domanda che questo era più per progetti personali dove forse fattori psicologici in più. Ma più lontano voterei per separare i pezzi di funzionalità molto disaccoppiati. Non devi necessariamente dividere il tuo quadro in tutti i pezzi che desideri subito. Cercherei solo di iniziare a creare librerie di codice stabili, ben collaudate, che siano di natura minima e disaccoppiata - cose che ti fanno stare bene per un bel po 'di tempo.