Quali sono i layout di directory standard per il codice sorgente, altre librerie, script di compilazione, ecc.? [chiuso]

2

Sto proponendo un nuovo layout di directory standard che verrà utilizzato in tutti i progetti della nostra organizzazione. I progetti possono avere codice sorgente compilato, script di configurazione, script di compilazione, librerie di terze parti, script di database, risorse, servizi Web, siti Web, ecc.

Ciò è in parte ispirato alla scoperta di layout standard di Maven .

Esistono altri layout standard generalmente accettati nel settore?

    
posta splattered bits 04.02.2011 - 22:10
fonte

4 risposte

4

Per .NET, c'è un'app chiamata Tree Surgeon che espone un albero di sviluppo per i progetti .NET. È un po 'datato e non sono sicuro di quanto sia standard, ma è un punto di partenza interessante.

Per i miei progetti esterni a .NET, tendo a configurare una cartella per il codice sorgente, una cartella per i test e una cartella per librerie di terze parti da cui dipendo. Ci sono spesso sottocartelle sotto ciascuna per consentire il raggruppamento per feature o spazio dei nomi.

In .NET, permetto a Visual Studio di organizzarsi e creare una cartella per la soluzione e quindi una cartella per progetto sotto di essa, anche se a volte corro i progetti di test in una sottocartella "Tests". Creo ancora la cartella "lib" per le dipendenze di terze parti e in genere va nella cartella della soluzione principale.

Per i progetti web puoi anche guardare framework come Rails, Django, ecc.

In generale, quando consideri il layout sorgente, assicurati che non finirai per combattere gli strumenti che usi per mantenerlo. Alcuni framework applicano i layout (Maven, Rails, ecc.) E non puoi fare molto. In alcuni casi andare contro corrente sarebbe solo un fastidio (come in Visual Studio), ma sarebbe un fastidio persistente con cui dovresti avere a che fare ogni giorno.

    
risposta data 04.02.2011 - 22:28
fonte
2

Sto appena iniziando a programmare, ma ho visto molti progetti usare questo:

  • src : dove posizioni il codice sorgente, generalmente nelle cartelle per gerarchia e nella struttura del progetto
  • bin : dove puoi posizionare i file compilati
  • script : dove puoi inserire, script per l'utente
  • test : dove puoi inserire script per testare il programma
  • documenti : dove posizionare i documenti che spiegano il progetto
  • esempi : dove devi inserire esempi su come utilizzare il progetto
  • dist : dove puoi inserire il pacchetto del codice sorgente non compilato
  • build : dove puoi posizionare le distribuzioni compilate, generalmente nelle cartelle per piattaforma
  • devi anche inserire lo script di costruzione / compilazione / distribuzione nella cartella radice del progetto, insieme a file come copyright e readmes

Ho trovato un documento Oracle che descrive e il layout standard per alcuni progetti, puoi vedere molte somiglianze:

link

modifica

Ha anche visto una cartella lib , immagino qui dovresti posizionare le librerie esterne, non ci ho pensato perché uso python dove strumenti come pip li scaricano e li installano automaticamente

    
risposta data 27.05.2015 - 00:27
fonte
0

In genere lo considero perché ci sono due cose diverse da considerare qui.

Layout generale

Questo tende ad essere la struttura di cartelle di alto livello che può essere in qualche modo influenzata dal provider del controllo sorgente. In genere sarà qualcosa sulla falsariga di

  • Progetto
    - Rami
    - Principale - Uscite

Main può essere suddiviso in altre cartelle generali (sorgente, documentazione, guida, ecc.) ma tale dettaglio dipende dalla società e da ciò che viene mantenuto accanto al codice sorgente nel provider del controllo sorgente. Ad esempio, i progetti in cui ho lavorato dove abbiamo utilizzato TFS le risorse non di origine (requisiti, progettazione, ecc.) Sono archiviati nel sito di SharePoint associato. La maggior parte dei progetti su cui ho lavorato negli ultimi 8 anni hanno avuto un sito CMS (simile) per archiviare e tenere traccia degli artefatti non-sorgente.

Codice sorgente

Come menzionato da Anna Lear, non combattere gli strumenti. Molti di noi usano IDE che forniscono per te un certo livello di layout di codice 'naturale'. Nella mia esperienza, in genere, la scelta più ampia (naturalmente fornita) è se si attaccano i test unitari in una cartella completamente separata dal codice di produzione o si mescolano. Una considerazione secondaria è che esiste un limite per quanto tempo può essere un percorso e se nidifichi troppo profondamente inizierai a incontrare problemi con la compilazione (forse un problema più grande con Windows di * nix, non ho lavorato su * nix fra poco). Nota che con la convenzione (almeno .NET) delle tue cartelle che creano la struttura del tuo spazio dei nomi in un progetto, questo può crescere piuttosto rapidamente se non lo tenete d'occhio. Mi piacerebbe pensare che molte / molte aziende si siano uniformate su come verrà presentata la fonte per qualsiasi lingua / tecnologia, ma non l'ho ancora vista.

    
risposta data 05.02.2011 - 04:57
fonte
-2

Come sottolineato dalla tua domanda, le strutture del progetto sono spesso il risultato del set di strumenti di generazione e di come gli strumenti degli sviluppatori sono progettati per gestire e organizzare il codice. Maven ha un layout rigoroso, che gli consente di fornire un processo di compilazione molto strutturato. Visual Studio impone una struttura di directory per i progetti Web MVC. Erlang / OTP / rebar crea un modo molto strutturato in cui sono presentati i progetti.

Pensa agli strumenti che stai usando e se impongono vincoli su di te, e poi ai bisogni degli umani nel progetto di classificare e comprendere la struttura del progetto.

Infine, come standard, deve essere documentato in modo chiaro e, cosa più importante, facilitato l'implementazione da parte dei tuoi colleghi.

    
risposta data 27.05.2015 - 09:21
fonte

Leggi altre domande sui tag