Partizionare il codice negli assiemi per motivi di separazione logica

Question

Partizionare il codice negli assiemi per motivi di separazione logica

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

3

Ho iniziato a lavorare in questa azienda e il software è gestito in una soluzione di Visual Studio che include centinaia di progetti (C ++ e C #). Dopo aver sondato la soluzione per un paio di settimane, ho iniziato a chiedermi perché ci sono così tanti progetti. Non solo rallenta notevolmente VS, ma una ricostruzione può richiedere fino a un'ora.

Poiché un progetto di studio visivo corrisponde a un'unità di distribuzione fisica (sia esso una dll .NET, una lib di C ++ o un exe), ci sono ragioni per cui si desidera che il codice venga partizionato tra i progetti. Alcuni di questi motivi possono essere trovati in questo articolo .

Nel mio caso particolare, nessuna delle ragioni in quell'articolo era. Esistono circa 5 processi in esecuzione su più livelli, forse alcuni assemblaggi caricati in modo dinamico utilizzati per un modello plug-in e alcune infrastrutture che vengono raramente modificate.

Non vedo alcun bisogno di più di ~ 50 progetti VS per questa soluzione, e credo che unirli aumenterà la produttività e consentirà un ciclo di feedback più breve.

Quando ho provato a suggerire questo al gestore del software, la sua risposta è stata che stanno cercando di avere il maggior numero possibile di DLL in modo che quando pianificano di inviare una nuova funzione, QA può testare solo il comportamento delle dll modificate senza doversi preoccupare che sia stato fatto qualcos'altro. Ha detto che dal momento che una dll non è stata modificata, si comporterà allo stesso modo. Affinché ciò funzioni, mirano a un'elevata granularità delle unità di implementazione.

Questo ha senso per chiunque? Non vedo la differenza nell'effetto sul comportamento tra la modifica di una singola riga in un progetto che ha una singola enorme dll e la modifica della stessa riga in un progetto che include centinaia di DLL.

Modifica

Sto cercando una risposta sull'utilizzo di assiemi / progetti come mezzo per separare le preoccupazioni logiche e il suo effetto sullo sforzo di test. Direi addirittura che molti assembly potrebbero darti più scenari di test a causa di incompatibilità con le versioni.

Quindi la mia domanda distillata è: Quando partirai il tuo codice su progetti / assiemi invece di spazi dei nomi nello stesso assembly, dato che non ci sono vincoli di runtime, e perché?

EDIT 2

Credo che sto cercando qualcosa come questo articolo . Tuttavia, sono riluttante a postare questa risposta come risposta e accetto prima di vedere se ci sono opinioni diverse nella community.

projects-and-solutions deployment dll qa

posta moranlf 17.09.2013 - 08:14

fonte

3 risposte

1

Penso che avere troppi progetti in un'unica soluzione sia una brutta cosa. In precedenza ho lavorato al sistema che comprendeva oltre 15 domini aziendali. Se dovessi metterli tutti in una soluzione, finirei con centinaia di progetti. Ti suggerisco di provare a suddividere questi progetti in soluzioni logiche (domini). In altre parole, lavora sulla separazione delle preoccupazioni.

Riguardo al tempo di costruzione, questo può normalmente essere migliorato. Avevamo un sistema che impiegava più di un'ora per costruire e dopo un anno di lavoro il tempo passava a meno di 10 minuti, il che è un enorme risparmio di costi.

risposta data 17.09.2013 - 09:27

fonte

0

Sì, ha un senso. Il problema è che è ancora altamente teorico. Lo interrogherei se ciò che dice, è davvero fatto nella pratica. Il QA verifica realmente le singole DLL o verifica solo le parti più grandi del progetto. Testano anche DLL che hanno modificato DLL come dipendenza? Se no, come sono in grado di garantire che funzioni correttamente? C'è anche il problema di monitorare effettivamente le modifiche per ogni DLL. Perché più DLL ci sono, più difficile è tenere traccia di quali DLL sono state modificate per funzionalità / bugfix specifici. L'ultima cosa che mi viene in mente è la separazione delle preoccupazioni. Se la struttura del progetto è corretta, molte modifiche richiederebbero solo alcune DLL. Preferibilmente solo uno. Questo è raramente un caso e il più delle volte, i progetti sono in uno stato tale che il cambiamento si propaga attraverso molte DLL. Alla fine è questione di compromesso: il vantaggio del test separato (con tutto ciò che ne consegue) è più alto di quello di avere tempi di compilazione davvero lunghi e di gestire l'inferno della DLL?

Gli chiederei sicuramente, se quello che dice è solo un pio desiderio o una pratica reale, che in realtà è vantaggioso.

risposta data 17.09.2013 - 08:40

fonte

Leggi altre domande sui tag projects-and-solutions deployment dll qa

Come caricare in un approccio iterativo agile? [chiuso] Argomenti per la conformità a PSR-2

score 3 · Accepted Answer

Il QA nel suo complesso riguarda la valutazione del rischio che il prodotto sia adatto agli utenti. In realtà, il QA non è una garanzia al 100%, in parte perché di solito è impossibile testare tutte le azioni possibili (comprese tutte le azioni non valide) in ogni ambiente possibile.

Dato che hai una risorsa QA limitata, devi prendere decisioni su dove focalizzare la risorsa per aumentare la probabilità di rilevare bug critici che sono stati persi dagli sviluppatori.

Il commento del QA sulle DLL che non cambiano significa che possono concentrare meglio i loro sforzi di test è corretto. Anche se, la correttezza è diminuita se la libreria non è stampata dalla versione del sistema autobuild (come si dimostra la sua stessa DLL?) E si sta avvicinando a sbagliato se è una nuova DLL compilata dallo stesso codice sorgente (ha fatto le opzioni del compilatore / modifica del set di strumenti - produzione di una libreria diversa?) ... e se non esiste alcun meccanismo che la QA svolga effettivamente per controllare che il codice sorgente tra le due DLL non sia cambiato, allora è decisamente sbagliato in quanto QA non può dire con certezza che un cambiamento non è scivolato dentro.

Ho lavorato su diversi team che hanno un numero elevato di progetti nello stesso file di soluzione. Ha funzionato meglio per alcuni rispetto ad altri. Le cose si deteriorano quando il numero di file di progetto aumenta a tal punto che Visual Studio inizia a diventare instabile. Tuttavia, su un'architettura ben progettata, che elabora al minimo le interdipendenze della DLL e ha un strong rilascio e un processo di gestione delle versioni, è possibile farlo funzionare bene.