Utilizzo di pacchetti (gemme, uova, ecc.) Per creare architetture disaccoppiate

Il problema principale

Vedendo il buon supporto la maggior parte delle piattaforme di programmazione moderni hanno per la gestione dei pacchetti (si pensi gem, npm, pip, ecc), ha senso per la progettazione di un'applicazione o di un sistema composto di pacchetti sviluppati internamente, in modo da promuovere e creare un'architettura loosely coupled?

Esempio

Un esempio di ciò sarebbe la creazione di pacchetti per l'accesso al database, nonché per l'autenticazione e altri componenti del sistema. Questi, ovviamente, usano anche pacchetti esterni. Quindi, il tuo sistema importa e utilizza questi pacchetti, invece di includere il loro codice nella propria base di codice.

considerazioni

A mio avviso, ciò favorirebbe il disaccoppiamento del codice e aiuterebbe la manutenibilità, quasi in un modo basato sul Web rispetto all'applicazione desktop (gli aggiornamenti vengono applicati quasi automaticamente, la base di codice singolo per funzionalità singola, ecc.).

Sembra un concetto di design razionale e sano? Questo è attualmente utilizzato come un modo standard di strutturare le applicazioni?

Sono stato coinvolto in progetti come questo due volte ora (entrambi usando nuget con .NET), e direi che a conti fatti è una buona idea. Ma il tuo chilometraggio può variare.

Non pensare per un minuto che è una panacea, che risolverà tutti i tuoi problemi senza causarne di nuovi. Gestione di uscita guadagnerà un intero nuovo livello di complessità, è necessario per affrontare le questioni versione di dipendenza non si sapeva mai esistito, e si avrà avere momenti in cui si maledici la decisione perché hai aggiornare quattro pacchetti diversi a causa di una piccolo bug che devi correggere e rilasciare rapidamente.

D'altra parte, hai ragione che disaccoppia bene le cose. A meno che non esagerare, probabilmente troverai più occasioni in cui pensi "oh, ha funzionato bene", che "ha aggiunto molto sforzo". Se hai il codice condiviso tra più applicazioni, è particolarmente efficace perché puoi facilmente aggiornare le tue app in modo indipendente.

E, se sei qualcosa come me, inizierai rapidamente a scrivere app di test che utilizzano i tuoi pacchetti, per rimuovere interi livelli di applicazione dal tuo processo di ricerca dei bug. E questo, di per sé, può valere più che i costi.

Questa è una buona idea, tutto sommato. Dovrai pensare di impostare un repository di pacchetti interno (di solito chiamato "repository di artefatti" nel mondo Java, o "server pypi" nel mondo Python), in modo da mantenere lì quei pacchetti che non vuoi o puoi ' Rilascio come open source.

Come ha notato @pdr, preparatevi ad avere la vostra inferno di dipendenza , dove una modifica ad un pacchetto richiede prima un'altra modifica in un altro pacchetto, e questo significa non solo cambiare una riga di codice, ma testarla, possibilmente accettando le modifiche, compilazione di una versione e caricamento della versione nel suddetto repository di pacchetti. E poi cambiando ciò che intendevi cambiare.

L'unica ricetta che posso darti dalla mia esperienza per cercare di minimizzare questo: non fare affidamento solo sull'astrazione di concetti comuni dai tuoi pacchetti in un pacchetto "comune" o "quadro" . Può sembrare una cosa molto obiettiva da fare, ma porterà a un pacchetto mostro che necessita di modifiche e rilasci frequenti, forse contraddittori. Molto meglio, pensa alle funzionalità del tuo sistema e crea un pacchetto di supporto per ognuna di esse, come hai delineato nella tua domanda.

A parte questo, il principale vantaggio che otterrai è che le tue app sono isolate da (molte) dipendenze, quindi puoi scambiarle senza dolore.