Best practice per le dipendenze locali di progettazione multi-modulo

6

Questa domanda potrebbe essere stata chiesta in precedenza e, in tal caso, sentirsi libera di collegarsi alla risposta. Sto cercando una ricetta moderna ed efficace per un problema comune. Ho un progetto con un modulo principale, A, che dipende da un altro modulo, B, che sviluppo separatamente. questo modulo ha 2-3 (C-E) altri moduli da cui dipende, ognuno dei quali appartiene anche a me. Alcuni si sentono a proprio agio localizzando tutti i moduli in un repository svn o Git. La mia esperienza e il mio istinto mi dicono che ogni modulo appartiene al repository individuale. Attualmente sto affrontando questo dilemma con un progetto NodeJS / Electron su cui sto lavorando ma il problema / soluzione è sicuramente agnostico per la tecnologia. Mentre non conosco abbastanza i moduli locali nel nodo, sono più che familiare con i concetti. Sto solo cercando di applicare al meglio ciò che ho imparato a questo progetto al momento.

Sto andando a ripetere i pro e i contro di entrambi gli approcci seguenti, come ho visto dai miei oltre 17 anni di esperienza. Sono interessato a come gli altri hanno affrontato questo problema ed è totalmente separato i moduli la strada da percorrere in questo giorno ed età? Ci sono nuovi trucchi per gestire le dipendenze locali che mi sono perse nel corso degli anni?

Tutto in un repository

Pro:

  • Tutto può essere compilato / debug facilmente come un programma completo nel classico modo di pensare.
  • Le modifiche apportate ai singoli moduli sono immediatamente visibili e rappresentate all'avvio del modulo principale. Tutto è "collegato" insieme.
  • Abbassare la barriera all'ingresso per gli ingegneri di livello medio-basso.

Contro:

  • La coesione del progetto soffre come sfocatura delle linee di confine delle responsabilità. (Troppo facile collegare il codice dagli imputati alle dipendenze e viceversa.)
  • Le build più lente sono più lente in quanto la logica aggiuntiva deve essere presa in considerazione per gestire la compilazione di ciascun modulo nell'ordine corretto e nel modo corretto.

Repositi separati

Pro:

  • Migliore coesione. Le linee di responsabilità sono chiaramente delineate
  • Riutilizzabilità immediata / immediata. (Per dimostrare che il modulo funziona, devi testarlo al di fuori del suo modulo dipendente che impone la riusabilità dall'inizio).
  • build più semplici e maneggevoli. Le dipendenze vengono create una volta per versione e il progetto principale deve solo dichiarare le sue dipendenze piuttosto che crearne ciascuna.

Contro:

  • Complessità aggiuntiva che itera cambiamenti nelle dipendenze del modulo. Una dipendenza deve essere costruita e amp; rilasciato (o semi-rilasciato) prima di essere eseguito nel modulo principale.
  • Aggiungi le complessità nel debug. Non è sempre possibile accedere alla fonte delle dipendenze con questo approccio, a seconda dello stack tecnologico e dell'approccio di assemblaggio dell'app generale.
  • Richiede più disciplina, maggiore barriera all'ingresso per gli ingegneri di livello medio-basso.

Ho menzionato l'impossibilità di entrare nel codice mentre eseguivo il debug come cono, ma questo non vale tanto per JavaScript, dove tutta la sorgente è sempre visibile. Tuttavia, mi trovo ancora ad affrontare delle difficoltà nel configurare il debugging nel mio IDE quando i moduli sono esternalizzati.

    
posta Cliff 13.05.2016 - 00:59
fonte

1 risposta

2

I miei due centesimi:

Utilizza repository separati su progetti condivisi.

In altre parole, se un progetto è utilizzato da più di un altro progetto (o inteso per essere utilizzato in più progetti, ad esempio una libreria), va nel proprio repository.

Stiamo soffrendo questo dolore dove attualmente lavoro. Ecco come si presenta la conversazione attuale:

ME: Shouldn't projects build straight from the source code repository, as a matter of policy?

SHE: Yes, they should. But we don't have a working CI server, and you can't expect to enforce this rule without one.

ME: Don't we have one of those?

SHE: Yes, but it's on a cloud server which doesn't have access to the shared drive where we keep the latest build binaries.

ME: Then why don't we just get the CI server to build those binaries for us?

SHE: Really, we should be taking project references instead of binary references. That way, we can be sure that each project has everything it needs to build.

ME: If you make me do that, you'll require me to take a dependency on the main repository that contains the common library. That repository is 39 separate projects in a single solution, is 1 gigabyte in size, and it won't build on my machine from the current repository. Why don't we just split out the common projects into their own repositories?

SHE: >_<

    
risposta data 13.05.2016 - 01:18
fonte

Leggi altre domande sui tag