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

Sono stato coinvolto in progetti come questo due volte (entrambi usano Nuget con .NET), e direi che on balance è una buona idea. Ma il tuo chilometraggio può variare.

Non pensare per un minuto che sia una panacea, che risolverà tutti i tuoi problemi senza causarne di nuovi. La gestione dei rilasci acquisirà un nuovo livello di complessità, dovrai affrontare i problemi di dipendenze delle versioni che non avresti mai saputo esistere e avremo momenti in cui devi imprecare contro la decisione perché devi aggiornare quattro diversi pacchetti a causa di un piccolo bug che è necessario correggere e rilasciare rapidamente.

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

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

Questa è una buona idea, tutto sommato. Dovrai pensare all'impostazione di un repository di pacchetti interni (di solito chiamato "repository di artifact" nel mondo Java, o "server di pypi" nel mondo Python), in modo da tenere lì quei pacchetti che non vuoi o puoi ' t rilasciare come open source.

Come ha notato @pdr, sii preparato ad avere il tuo dannoso accesso alle dipendenze , in cui una modifica ad alcuni pacchetti richiede prima un altro cambiamento in un altro pacchetto, e questo significa non solo cambiare una linea di codice, ma testarla, possibilmente accettando le modifiche accettate, costruendo un rilascio e caricando la release nel repository di pacchetti sopra menzionato. E poi cambiare ciò che ha voluto per cambiare.

L'unica ricetta che posso darti dalla mia esperienza per cercare di minimizzare questo: non fare affidamento esclusivamente sull'astrazione di concetti comuni dai tuoi pacchetti in un pacchetto "comune" o "quadro" . Questo può sembrare una cosa molto obiettiva da fare, ma porterà a un pacchetto di mostri che ha bisogno di cambiamenti 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 indicato nella tua domanda.

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