Sì, scrivere biblioteche con codice comune è una buona pratica. Mentre il copia / incolla potrebbe farti risparmiare un po 'di lavoro inizialmente, quasi sicuramente ti verrà garantito il pagamento più tardi, perché nel momento in cui devi apportare modifiche al codice comune, devi ricordare tutti i luoghi che sono stati copiati / incollati. Inoltre, se qualcun altro si assume la responsabilità di mantenere queste applicazioni in futuro, dovrà anche sapere dove si trova il codice duplicato.
L'approccio comune che ho visto in pratica (in. NET) è stato quello di confezionare codice comune come librerie Nuget e servirle dal proprio server Nuget.
Tuttavia, nella mia esperienza ci sono alcuni svantaggi di cui dovresti essere a conoscenza quando inizi a creare librerie comuni per più applicazioni. Ad esempio, alcuni sviluppatori tendono a dimenticare il sovraccarico di mantenere più versioni di queste librerie comuni. A meno che non stiate pianificando di aggiornare tutte le vostre applicazioni alla versione più recente della vostra libreria non appena la rilasciate (il che è improbabile), dovrete mantenere diverse versioni della vostra libreria per la compatibilità con le versioni precedenti, specialmente se introducete modifiche irrisolte.
Allo stesso modo, se sei l'unico a produrre e consumare queste librerie come indica la tua domanda, dovresti anche stare molto attento quando decidi cosa consideri un codice "comune" e come queste librerie vengono consumate. Se ti ritrovi a modificare una libreria di codice comune perché una singola applicazione che lo consuma richiede la modifica, il codice probabilmente non è comune. Inizialmente, come regola generale, creerei librerie per problemi trasversali come la registrazione, il monitoraggio e la gestione degli errori che sono ovviamente comuni alle tue applicazioni. È quasi sempre più facile ricopiare il codice in una libreria piuttosto che rompere una dipendenza su una libreria che risulta non essere così comune.
Come produttore e consumatore delle tue biblioteche, corri il rischio di accoppiare strettamente i tuoi utenti con l'implementazione della libreria. Rischia anche di rendere le interfacce della libreria specifiche per il consumatore piuttosto che generiche. Cerca di consumare le tue librerie utilizzando un approccio comune a tutte le tue applicazioni. Per lo meno, dovresti provare a creare un livello di astrazione "anti-corruzione" tra l'applicazione e il codice che utilizza la libreria.
Ad esempio, se si utilizza una pipeline OWIN in un'applicazione ASP.NET MVC, è possibile inserire il codice comune come middleware, che separerebbe il consumo di queste librerie dal codice che implementa la logica aziendale nell'applicazione. Se non si è in grado di deprecare una libreria comune o modificare la sua interfaccia pubblica senza richiedere modifiche alla logica di business nella propria applicazione, direi che la stai consumando in modo errato. Allo stesso modo, quando crei un'interfaccia pubblica per la tua libreria, assicurati che possa essere utilizzata da qualsiasi applicazione.
Se non è ovvio per la mia risposta fino ad ora, la creazione di librerie comuni da condividere tra le applicazioni non è così semplice come il raggruppamento di codice duplicato. È probabile che tu possa sbagliare la prima volta che lo provi (lo so che l'ho fatto) e saranno delle lezioni dolorose. Non lasciarti scoraggiare, perché, secondo la mia esperienza, i dolori in crescita meritavano i benefici.
Prima di proseguire su questa strada, ti suggerirei di saperne di più sull'argomento. Un buon punto di partenza (per .NET) è la linea guida per la progettazione di framework di Microsoft:
link
Ci sono anche una serie di buoni libri scritti su questo argomento.