Perché un team di sviluppo dovrebbe insistere sul fatto che l'utilizzo di un'unica soluzione per più progetti in Visual Studio "accresca la complessità dell'interdipendenza"?

Non è necessario dir loro come strutturare i loro progetti. Piuttosto, è necessario che tu possa creare il sistema dal sorgente eseguendo un singolo script, senza ottenere alcun errore. Se gli script eseguono Visual Studio o Msbuild o altri strumenti e se vengono chiamati una volta, 50 o 100 volte non dovrebbero avere importanza.

In questo modo, si ottiene lo stesso "test di completezza" del codice come si otterrebbe mettendo tutto in un'unica soluzione. Ovviamente, questo script non ti dice se il team ha veramente controllato l'ultima versione dal loro controllo sorgente, ma avere l'intero codice in una soluzione non lo controlla,

Come risposta a "l'interdipendenza tra i moduli aumentati se tutto è collocato in un unico file di soluzione" - questa è una dimostrabile assurdità, poiché aggiungere progetti a una soluzione non non modificare nessuna delle dipendenze tra i progetti, le dipendenze sono il risultato di un file di progetto che fa riferimento a un altro, che è completamente indipendente da quale soluzione fa riferimento a quale file di progetto. Nessuno impedisce a quel team di avere entrambi - una soluzione unica che fa riferimento a tutti i progetti, e anche soluzioni individuali, ciascuna delle quali fa riferimento a un solo progetto.

Tuttavia suggerirei di aggiungere uno script di compilazione. Ciò ha benefici anche quando esiste un solo file di soluzione. Ad esempio, consente di eseguire una build VS con una configurazione preferita, di copiare i file finali per la distribuzione (e nient'altro) in una cartella "deploy" e di eseguire altri strumenti e passaggi per completare la compilazione. Vedi anche F5 non è un processo di compilazione! , e Il test di Joel .

Dipenderà da quanto vengono riutilizzati gli assembly compilati. Se non viene riutilizzato l'assemblaggio, non vi è alcun motivo reale per tenere separati i "moduli". In effetti nella mia esperienza questo è più di un ostacolo.

Nel team di sviluppo di cui faccio parte abbiamo librerie indipendenti che abbiamo scritto utilizzate in più prodotti come soluzione separata, che in questo caso ha senso altrimenti dovremmo compilare l'applicazione A per mantenere l'applicazione B in su fino ad oggi, che potrebbe essere necessario per mantenere l'applicazione C aggiornata.

Ogni prodotto è mantenuto nella propria soluzione, anche se ci sono più progetti che compongono il prodotto. In questo modo dobbiamo solo costruire la soluzione Libreria per mantenere aggiornato il suo codice condiviso in tutti i prodotti sviluppati.

Ogni azienda di software per la quale ho lavorato ha avuto un team di sviluppo principale che ha fornito il ramo principale che copre i casi d'uso fondamentali dei prodotti dell'azienda.

Gli sviluppatori di filiali che utilizzano il repository principale sono responsabili della scoperta dei miglioramenti e dell'invio delle richieste di pull al ramo principale per la revisione. Questo è solitamente il modo in cui uno diventa uno sviluppatore principale, mostrando che si può dare un contributo migliore rispetto al semplice fiammeggiare le fiamme di un conflitto architettonico.

È probabile che la tua azienda semplicemente non disponga delle risorse per "unificare tutti i codici di riferimento con un'unica soluzione". Suggerire di farlo senza comprendere i propri vincoli di budget è (almeno) probabile che impedisca a uno di diventare un ingegnere di base.

Quindi formuli la tua visione generale in poche e devastanti richieste di attrazione verso il nucleo, e preparati a difenderti in revisione!

C'è un nucleo di verità nell'affermazione "L'uso di una singola soluzione per più progetti aumenta la complessità dell'interdipendenza".

Una singola soluzione fa riferimento a un progetto da un altro progetto (cioè riutilizzando il codice di un progetto a.k.a. "introducendo la complessità di interdipendenza") più semplice:

• invece di sfogliare l'intero file system / cache di assembly globale per l'assembly di riferimento, è possibile selezionare il progetto da una serie limitata di progetti rilevanti nella soluzione; e,
• durante la lettura del codice sorgente è molto più semplice passare a un progetto di riferimento nella soluzione piuttosto che a un assembly arbitrario (binario).

Quindi nelle mani di un team indisciplinato che utilizza più progetti in un'unica soluzione può portare a molte dipendenze trascurate. Tuttavia, un team può provare meglio ad apprendere la disciplina necessaria per gestire attentamente le dipendenze e quindi utilizzare la facilità di riutilizzo che utilizza l'offerta di soluzioni.