Stiamo per iniziare con un nuovo software e ci sono opinioni contrastanti sull'organizzazione del software. Sarei lieto di ascoltare ciò che gli altri potrebbero avere da dire riguardo alle opzioni presentate e su quale altra considerazione si possa fare quando si prende una simile decisione.
- Approccio gerarchico
- Approccio intercambiabile
L'approccio n.1 consisterebbe in un'unica soluzione in VS con un numero di progetti ad essa collegati (come Utilità , Servizio , Esportatore , Gui ecc.). Tutto sarebbe in una singola raccolta e nella stessa directory radice (per il file della soluzione) e nelle sottodirectory (per i file di progetto), per così dire.
L'approccio n. 2 sarebbe costituito principalmente da un insieme di progetti, non correlati tra loro (diversi dai riferimenti, ovviamente), mentre le soluzioni (o le soluzioni ', vorremmo creare configurazioni diverse per consegne diverse) scopo sarebbe esclusivamente di fare riferimento ai progetti (esterni) che li raccolgono nella GUI. Ci sarebbero n + 1 directory (una per ogni file del progetto e una aggiuntiva per il file della soluzione, o i file delle soluzioni in seguito).
Abbiamo discusso la questione e elencato i vantaggi di ciascun approccio e, sebbene concordati sui fatti, i membri del team non sono sulla stessa pagina per quanto riguarda quale scegliere. Siamo un'organizzazione molto democratica, quindi la decisione deve essere persuasiva per tutti (o almeno una grande maggioranza) e non ci sarà alcun ordine da parte del capo. Non esiste una base di codice precedente e la considerazione finanziaria non deve essere affrontata.
Quale approccio è preferibile? Qual è più uno standard comunemente applicato nel settore? Quali considerazioni si potrebbero fare per garantire la rigidità della scelta?
È anche possibile che il nostro attuale progetto sia soggetto alla situazione descritta in questa domanda - sia quello che" prende in prestito "progetti da altrove sia quello da cui i progetti sono" presi in prestito ".