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

Sto aiutando a gestire un team esterno che sta iniziando a sviluppare nuove versioni di alcuni prodotti esistenti. Storicamente, questo team ha sempre usato un modello di un singolo progetto in un'unica soluzione per circa 30 moduli in Visual Studio che si uniscono per produrre una build distribuibile.

Ciò sta avendo un impatto negativo sull'affidabilità e sulla qualità della costruzione, perché non sempre ci inviano il codice sorgente più aggiornato. Stiamo provando a spingerli per unificare tutto il codice di riferimento in un'unica soluzione, ma stiamo ottenendo una certa resistenza - in particolare continuano a parlare dell'interdipendenza tra i moduli (leggi i "progetti" in Visual Studio) che aumenta se tutto viene inserito in un singolo file di soluzione. Nessun codice nelle soluzioni separate viene utilizzato altrove.

Insisto che questa è una sciocchezza e che buoni schemi di sviluppo eviteranno questo problema.

Il team in questione esegue anche correzioni di bug e sviluppo di nuove funzionalità su un prodotto esistente, la cui esperienza è stata a dir poco esagerata e soffre esattamente dello stesso problema di suddivisione su più soluzioni. Ci è stato rifiutato l'accesso al loro controllo del codice sorgente ( TFS ) e l'approccio che stiamo adottando per unificare la base di codice è provare e almeno ridurre il numero di aggiornamenti mancanti e più che regressioni occasionali (sì, i bug corretti vengono ri -introdotto nel prodotto) dicendo "inviaci un ZIP dell'intera cartella della soluzione in modo che possiamo decomprimerlo, aprirlo in Visual Studio e premereF5 per i test ". In termini di struttura e qualità generali, il codice è piuttosto scarso e difficile da supportare. Questa esperienza è il motivo per cui sono intenzionato a ottenere i processi di lavoro il più presto possibile nel ciclo di sviluppo.

C'è qualcosa che mi manca? C'è mai una buona ragione per tenere tutto quel codice separato? Per i miei soldi dovrebbe essere una ragione così convincente da essere conoscenza comune, ma sono più che disposto a ammettere di non sapere tutto.

Non è necessario dire loro come strutturare i loro progetti. Invece, è un requisito difficile che è possibile creare il sistema dall'origine eseguendo un singolo script, senza ottenere errori. Se tali script eseguono Visual Studio o Msbuild o altri strumenti e se quelli vengono chiamati una volta, 50 o 100 volte non dovrebbero avere importanza.

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

In risposta a "l'interdipendenza tra i moduli in aumento se tutto viene inserito in un unico file di soluzione" - questa è una sciocchezza dimostrabile , poiché l'aggiunta di progetti a una soluzione non modifica nessuna delle dipendenze tra i progetti, le dipendenze sono il risultato di un progetto file 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: un'unica soluzione che fa riferimento a tutti i progetti e anche singole soluzioni che fanno riferimento a un solo progetto.

Tuttavia suggerirei di aggiungere uno script di build. Ciò ha vantaggi 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 build. Vedi anche F5 non è un processo di compilazione! e The Joel Test .

Dipenderebbe da quanto riutilizzeranno gli assembly compilati. Se non è possibile riutilizzare gli assiemi, non esiste alcun motivo reale per mantenere separati i "moduli". In effetti nella mia esperienza questo è più di un ostacolo.

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

Ogni prodotto viene mantenuto nella propria soluzione, anche se ci sono più progetti che lo compongono. In questo modo non ci resta che creare la soluzione Library per mantenere aggiornato il suo codice condiviso in tutti i prodotti sviluppati.

Ogni società di software per cui ho mai lavorato aveva un team di sviluppo principale che ha fornito la sede principale che copre i casi d'uso di base dei prodotti dell'azienda.

Gli sviluppatori di succursali che utilizzano il repository principale sono responsabili della scoperta di miglioramenti e dell'invio di richieste pull al ramo principale per la revisione. Questo è in genere il modo in cui si diventa uno sviluppatore principale, dimostrando che si può dare un contributo migliore piuttosto che accendere le fiamme di un conflitto architettonico.

È probabile che la tua azienda semplicemente non abbia le risorse per "unificare tutto il codice di riferimento in un'unica soluzione". Suggerire di farlo senza comprendere i loro vincoli di bilancio è (almeno) probabile che impedisca a uno di diventare un ingegnere di base.

Quindi formula la tua grande visione in alcune richieste di pull devastanti fino al midollo e preparati a difenderti in revisione!

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

Una singola soluzione semplifica la referenziazione di un progetto da un altro progetto (ovvero il riutilizzo del codice di un progetto noto anche come "introduzione della complessità dell'interdipendenza"):

• 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 pertinenti 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 (binario) arbitrario.

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