Perché sviluppare librerie interne per applicazioni interne?

Ci sono numerosi motivi per creare librerie e amp; librerie condivise, (in file .dll o .so) anche per uso interno:

1. Riutilizzare i progetti è molto più pulito
2. Separazione di responsabilità - parte del tuo codice potrebbe essere più adatta a diversi sviluppatori o team
3. Puoi trarre vantaggio dai miglioramenti apportati alle librerie realizzate da altri team senza dover individuare il codice specifico
4. Tempi di costruzione più rapidi, se la libreria è stabile non ha bisogno di ricostruire.
5. Spazio su disco - puoi avere solo la libreria e le intestazioni nel progetto
6. Se utilizzi le librerie condivise puoi risparmiare sulla memoria con una sola copia caricata nella RAM anche se molti programmi la stanno usando
7. In genere si finisce con una documentazione e un test migliori delle librerie
8. Progettazione e codice più puliti - il pensiero di strutturare le cose nelle librerie dovrebbe risultare in gruppi correlati di funzionalità in ogni libreria e si tende a separare il codice generico, nelle librerie , dalle specifiche dell'applicazione, nell'app .
9. Se disponi di algoritmi proprietari nelle librerie, puoi limitare l'accesso alla fonte, ad es. non consentire agli appaltatori o ai team di sourcing di arrivare alla fonte.
10. Il codice della libreria può essere collocato sotto una licenza diversa per l'applicazione in cui era stato originariamente scritto come parte di, alcune aziende sono anche note alle librerie Open Source di cui sono orgogliosi - ottenere grandi riconoscimenti nell'Open Source comunità e alcuni importanti miglioramenti apportati indietro.

Alcune società hanno persino uno studio contabile in cui i progetti che creano biblioteche ricevono un rimborso per ogni riutilizzo.

Alcuni altri possibili motivi che possono essere applicati a progetti più grandi e non banali:

• Tempi di compilazione: Enormi progetti CITE monolitici con migliaia di file, migliaia di classi, funzioni, ecc. possono richiedere molto tempo per essere compilati (il che danneggia la produttività se si desidera ricompilare ogni volta che modifichi alcune righe di codice). Le librerie collegate in modo statico e collegate dinamicamente sono compilate in modo indipendente e non devono essere ricompilate se la loro origine non è cambiata.

• Separazione logica di moduli o sottosistemi distinti : i sistemi di grandi dimensioni sono in genere più facili da gestire se aree distinte di funzionalità sono collocate in moduli separati e gli sviluppatori non devono affrontare la ricerca in enormi cartelle / progetti contenenti migliaia di file / classi.

• Confini tra sviluppatori / team : gli sviluppatori che sviluppano nuove funzionalità separate allo stesso tempo potrebbero ridurre il rischio di conflitti di unione se è possibile avere ciascuno sviluppatore che lavora in moduli diversi.

• Codice che non deve essere rilasciato in un ambiente live : ad esempio, librerie di test di unità o librerie 'mock' che vengono utilizzate per i test degli sviluppatori per sostituire un componente di sistema live (hardware , API, sistemi remoti, database, ecc.)

• Flag del compilatore : se ti trovi nella sfortunata posizione di integrarsi con l'API di terze parti che si aspetta uno strano flag di compilazione, allora la libreria può essere uno "strato di decontaminazione" seduto tra l'API di terze parti e il resto dell'applicazione.

• Funzioni opzionali / Ottimizzazione : nei sistemi di grandi dimensioni, un'applicazione potrebbe attendere prima di caricare determinati moduli collegati dinamicamente in memoria in fase di esecuzione se non sono fondamentali per la funzionalità di base dell'applicazione.

In generale, molti progetti interni sono spesso piccole micro-app che non traggono vantaggio dalla suddivisione in librerie separate. Se stai lavorando su un piccolo progetto come sviluppatore solitario, allora non dovresti preoccuparti di suddividere il tuo codice in librerie (ancora ...). Non dimenticare il principio YAGNI .

La tua domanda originale potrebbe aver causato qui un equivoco per la maggior parte di quelle altre risposte. Poiché non intendi copiare il codice esistente tra i progetti, ma includere gli stessi file di origine di diversi progetti come riferimenti , qualsiasi argomento "codice duplicato" diventa inutile, così come molti altri argomenti presentati.

Nota a volte questo è (- non sempre) una tecnica sensibile . Infatti, quando si inseriscono tutti i file sorgente che si desidera riutilizzare tra i progetti in una cartella separata, è già stata creata una libreria - una libreria di codice sorgente, non una libreria binaria. Soprattutto in C ++, quando si creano librerie generiche con modelli, non è raro avere librerie di sola intestazione, che hanno solo bisogno di una semplice inclusione e di preparazioni di collegamento separate.

Quindi immagino che la tua vera domanda sia - quando costruire le librerie del codice sorgente, o quando preferire le librerie binarie precompilate? In questa risposta precedente su questo sito , ho discusso alcuni pro e contro delle librerie di sola intestazione, forse ti aiuta . Il vantaggio principale delle librerie di codice sorgente è che non richiedono di essere compilati con gli stessi flag di compilazione / linker di runtime e / o compatibili dell'applicazione che li utilizza. Gli svantaggi sono i tempi di compilazione aggiuntivi e il requisito di fornire l'accesso al codice sorgente (che ovviamente non è un problema per il tipo di progetti "interni" che hai in mente).

Sono d'accordo con altri commentatori quando scrivono che non dovresti duplicare il codice. Nel tuo caso, tuttavia, sembra che tu (o le persone con cui lavori) stiano creando librerie per codice che non duplicato altrove.

In questo caso, presta attenzione alla generalizzazione prematura . Spesso ci sono momenti in cui sembra un pezzo di codice sarà riutilizzabile. Tuttavia, senza conoscere i dettagli intimi di come il secondo caso d'uso userà tale codice, è molto facile dedicare più tempo alle funzioni di "riusabilità" che in realtà non saranno utili nei casi aggiuntivi o per fare supposizioni che si rivelano errate il secondo caso.

Scrivere una "biblioteca" per un caso d'uso può trasformarsi in un esercizio molto costoso senza alcun compenso --- Sono stato morso da questo più volte.

Costi di esempio:

1. Tempo / energia spesi nel considerare casi d'uso "generali"
2. Tempo trascorso a rendere la "libreria" distribuibile al tuo "cliente" (il tuo codice)
3. Pressione futura di utilizzare la "libreria" anche se non corrisponde completamente al caso d'uso successivo

La mia regola generale è: non creare codice in una libreria a meno che non disponga di almeno 2 posizioni separate in cui è necessario il codice.

why should an internal library be developed just to be linked to an internal application when I have access to the header and implementation files and can just include them in my source tree and compile them all together?

Perché se "li includi solo nel mio albero dei sorgenti", sei duplicare il codice .

Il problema è che non potrai beneficiare di alcun miglioramento (incluse le correzioni critiche dei bug) apportate dal progetto da cui hai copiato il codice, né trarranno vantaggio da eventuali miglioramenti apportati.

Potresti pensare di poter risolvere questo problema semplicemente copiando regolarmente la nuova versione del codice nell'albero dei sorgenti, magari persino automatizzata usando un sottomodulo in git o qualcosa di simile. Ma a causa di modifiche API incompatibili, la generazione si interromperà costantemente. D'altra parte, una libreria ha un'API pubblica "ufficiale" che i suoi sviluppatori sanno che non possono essere cambiati senza coodinarsi con i clienti.

Infine, potrebbero esserci motivi tecnici - potrebbe essere necessario mantenere una parte del codice come libreria, in modo che possa essere caricata opzionalmente o anche caricata e scaricata su richiesta, e quindi ridurre l'utilizzo della memoria quando la funzionalità non è necessaria?

Vorrei approfondire i costi della soluzione a lungo termine.

Chiaramente, l'aggiunta di una libreria a un progetto ha un sovraccarico, il tutto sopra se è il primo: i flussi di lavoro devono essere cambiati, a volte anche l'infrastruttura e alcuni membri del team potrebbero non gradirlo (all'inizio). Quindi i vantaggi della tua soluzione sono ovvi, poiché impone meno costi ora .

Tuttavia, con la crescita del progetto, anche i costi della "pseudo-biblioteca" andranno a buon fine. Supponiamo di avere una "pseudo-libreria" A che viene usata da un'applicazione e da un tester di unità. Ogni volta che aggiungi un cpp a A , devi aggiungerlo a entrambi i progetti, altrimenti non collegheranno.

Che cosa succede se la tua "pseudo-libreria" viene utilizzata da un'altra "pseudo-libreria" B ? Devi aggiungere il tuo nuovo cpp in un gruppo di progetti in più. E se B passa a utilizzare un'altra libreria? Dovrai eliminare i cpp da A in tutti i progetti, a seconda solo di B .

Tutto questo sarebbe gratuito se venisse utilizzata una vera libreria. Quindi la domanda è: quanti cpp sono necessari per giustificare il passaggio a una vera libreria?

Ma aspetta, c'è ancora più garanzie: a uno sviluppatore non piace questo stupido lavoro di cacciare tutti i progetti che necessitano del nuovo cpp down e aggiungerà il suo codice / classi da qualche parte in file già esistenti, che non è un cosa buona a lungo termine.

Quindi usare la "pseudo-libreria" può essere il primo passo per spezzare un progetto monolitico, ma non dovresti aspettare troppo a lungo per renderlo una vera libreria per poterne sfruttare i vantaggi.

But why should an internal library be developed just to be linked to an internal application when I have access to the header and implementation files and can just include them in my source tree and compile them all together?

Se la libreria viene utilizzata sempre solo dall'applicazione one , probabilmente non è necessario come libreria separata.

Se la libreria è utilizzata da 3.500 applicazioni, è do assolutamente necessaria come libreria separata.

Che cosa succede se c'è un bug nella libreria e devi risolverlo? O sono arrivati alcuni cambiamenti statutari o normativi che significano che hanno per cambiare il modo in cui la libreria funziona?

Se si trova in una libreria separata, è possibile (potenzialmente) correggere la libreria, riesaminarla e ridistribuirla e ogni applicazione trae beneficio dalla correzione.

Se è solo nel codice sorgente che è "locale" per ogni applicazione, allora devi cambiare, ricostruire, ricontrollare e ridistribuire ogni applicazione individualmente . È un esercizio molto più grande (vale a dire più costoso).