Come organizzi le cartelle dei tuoi progetti? [chiuso]

14

Buon pomeriggio

Mi piacerebbe sapere come organizzate le vostre cartelle di progetto?

Ho avuto una volta un capo che mi suggeriva di organizzare per i clienti.

Projects
|
|----Customer 1
     |---- A Cool Solution 1
           |---- source
                 |---- version1.0
                 |---- version1.1
           |---- docs
                 |---- analysis
                 |---- meetings
                 |---- manuals
|----Customer 2
|----Customer 3

Un mio amico mi ha detto di organizzare tem by Technology

Projects
|
|----.NET
     |---- C#
          |---- Customer 1     
                |---- A Cool Solution 1
                      |---- source
                            |---- version1.0
                            |---- version1.1
                      |---- docs
                            |---- analysis
                            |---- meetings
                            |---- manuals
|----Ruby
|----PHP

E tu? Hai un modo intelligente di organizzare le cartelle del tuo progetto?

    
posta Junior M 25.10.2010 - 22:43
fonte

6 risposte

6

Questo è quello che stavamo usando:

Projects
|
|----Customer A
     |---- Project 1
     |     |---- BuildControl       (CI/nAnt/Make/MSBuild files and config, etc)
     |     |---- Documentation      (In XML format so we can 'build' them)
     |     |---- Source
     |     |     |---- Component X
     |     |     |---- Component X.tests
     |     |     |---- Component Y 
     |     |     |---- Component Y.tests
     |     |---- Testing
     |     Project 1.sln      (Has folders as per project on-disk structure)
     |---- Project 2
     |---- Shared/Common components
|----Customer B
|----Customer C
|----<Our Company>
     |---- Internal Project A
     |---- Internal Library B

Da anni utilizziamo questa struttura per più progetti con molti clienti diversi e funziona molto bene.

È molto simile al tuo suggerimento iniziale, ma usiamo il controllo della versione per gestire il controllo delle versioni. I repository del server sono denominati "Customer X - Project Y", piuttosto che qualsiasi altra cosa. Questo ci consente di avere appaltatori esterni che lavorano su alcuni progetti ma non in grado di accedere ad altri in quanto possiamo impostare permessi sulla root di controllo della versione.

Ognuno controlla le proprie copie di lavoro ovunque vogliano sulla propria macchina di sviluppo (Windows) e usa il comando SUBST per mappare una lettera di unità in quella posizione. In questo modo possiamo avere percorsi relativi hard-coded nei file di build, ecc, che funzionano attraverso l'installazione di tutti. Quindi, per esempio, possiamo avere collegamenti a librerie condivise, se lo desideriamo. Di solito usiamo link / alias per il controllo della versione per raggiungere questo obiettivo.

Un grande vantaggio di questa struttura è che puoi isolare il codice dei clienti gli uni dagli altri. Ciò è utile se è necessario (a) inviare loro aggiornamenti regolari dell'origine per scopi di integrazione, (b) avere appaltatori esterni che lavorano su parti selezionate del codice.

Il tuo secondo suggerimento non funzionerà molto bene con un progetto complesso che utilizza più di una tecnologia.

    
risposta data 25.10.2010 - 23:54
fonte
8

Sono piuttosto piatto:

/ Progetti

Alcune variabili arrivano a seconda della casella, ma dietro ci sono solo molte cartelle individuali per i progetti. Il vero affare vive comunque nel controllo del codice sorgente, quindi questa è solo la casa temporanea locale.

    
risposta data 25.10.2010 - 23:06
fonte
3

Ho una struttura che sembra vagamente simile alla seguente:

~/
|-- Developer/
|   |-- Projects/
|   |   |-- Archives/
|   |   |-- Current/
|   |   |-- Work/
|-- Projects -> ~/Developer/Projects/Current

Archives contiene vecchi progetti su cui non sto più lavorando. Work contiene progetti relativi al lavoro. Current è tutto lo sviluppo attuale. Quindi, nella mia home directory, leggo symlink Projects a ~/Developer/Projects/Current . ~/Projects include anche collegamenti simbolici ad alcuni progetti di lavoro.

    
risposta data 25.10.2010 - 22:59
fonte
3

Ho anche una struttura piatta.

/ Progetti

Accettando con Wyatt Barnett, un vero affare vive comunque nel controllo del codice sorgente.

Voglio solo aggiungere che non dovrebbe esserci nulla di speciale sulla struttura delle cartelle, dal momento che molti IDE forniscono comunque collegamenti a progetti / file recenti. E quanti progetti lavora su nessuno? Veramente, solo per definizione, quelli recenti.

Inoltre, aggiungo solo i progetti recenti nella cartella di primo livello. Archivia tutte le cose più vecchie e completate in:

/ Projects / Old_stuff

o qualcosa del genere. Archivo ciò su cui generalmente non lavorerò di nuovo.

    
risposta data 26.10.2010 - 00:10
fonte
3

In passato ho utilizzato repository di Subversion per archiviare i miei documenti di origine e ho seguito la convenzione "project-minor" per l'organizzazione di repository, che ho trovato che funziona molto bene per le organizzazioni grandi e piccole.

struttureremmo i nostri rami di deposito; tag & tronco come segue:

branches-+
         +-personal-+
         |          +-alice-+
         |          |       +-shinyNewFeature
         |          |       +-AUTOMATED-+
         |          |                   +-shinyNewFeature
         |          +-bob-+
         |                +-AUTOMATED-+
         |                            +-bespokeCustomerProject
         +-project-+
                   +-shinyNewFeature
                   +-fixStinkyBug
tags-+
     +-m20110401_releaseCandidate_0_1
     +-m20110505_release_0_1
     +-m20110602_milestone
trunk

All'interno del vero albero dei sorgenti stessi, useremmo (qualcosa di simile) la seguente struttura:

  (src)-+
        +-developmentAutomation-+
        |                       +-testAutomation
        |                       +-deploymentAutomation
        |                       +-docGeneration
        |                       +-staticAnalysis
        |                       +-systemTest
        |                       +-performanceMeasurement
        |                       +-configurationManagement
        |                       +-utilities
        +-libraries-+
        |           +-log-+
        |           |     +-build
        |           |     +-doc
        |           |     +-test
        |           +-statistics-+
        |           |            +-build
        |           |            +-doc
        |           |            +-test
        |           +-charting-+
        |           |          +-build
        |           |          +-doc
        |           |          +-test
        |           +-distributedComputing-+
        |           |                      +-build
        |           |                      +-doc
        |           |                      +-test
        |           +-widgets-+
        |                     +-build
        |                     +-doc
        |                     +-test
        +-productLines-+
        |              +-flagshipProduct-+
        |              |                 +-coolFeature
        |              |                 +-anotherCoolFeature
        |              |                 +-build
        |              |                 +-doc
        |              |                 +-test
        |              +-coolNewProduct-+
        |                               +-build
        |                               +-doc
        |                               +-test
        +-project-+
                  +-bigImportantCustomer-+
                  |                      +-bespokeProjectOne
                  |                      +-bespokeProjectTwo
                  +-anotherImportantCustomer-+
                                             +-anotherBespokeProject

L'idea era (ed è tuttora) di utilizzare la struttura del repository per aiutare a strutturare la comunicazione tra il team di ingegneri; la parte del business rivolta al cliente e vari altri stakeholder & esperti di dominio.

Per arguzia: i documenti sorgente che si trovano in una delle directory "progetto" vengono utilizzati (e guadagnati) solo una volta. I documenti che si trovano in una delle directory "productLines" guadagnano denaro tutte le volte che viene venduto un prodotto da quella particolare linea. I documenti che si trovano in una delle directory "librerie" guadagnano denaro tutte le volte che vengono venduti i prodotti che li utilizzano.

Rende esplicita la nozione di ammortamento dei costi e aiuta a creare supporto per il riutilizzo dei documenti di origine in tutta l'azienda.

In un mondo ideale, il cliente che si trova di fronte a una parte dell'azienda utilizzerà anche questa struttura per archiviare presentazioni e amp; altre garanzie di vendita, in modo che gli sviluppatori possano vedere quali aspettative dei clienti sono state create, accanto alla directory dei prodotti pertinente, e i colleghi che affrontano i clienti possono monitorare lo sviluppo delle funzionalità e dei prodotti che stanno vendendo.

Significa anche che esiste una struttura comune sulla quale possono operare i nostri strumenti di automazione delle build. (I nostri script di build percorrono l'albero dei sorgenti alla ricerca di cartelle "build" all'interno delle quali trovano i file di configurazione che specificano come ciascun componente deve essere costruito, un processo simile accade per la generazione e il test della documentazione). Di nuovo, in un mondo ideale, il sito web dell'organizzazione e altri materiali di marketing potrebbero essere costruiti allo stesso modo.

Come ultima nota; il sistema di integrazione continua sa che è necessario attivare una build; analisi statica; test del fumo e amp; Il test dell'unità viene eseguito ogni volta che viene modificato il trunk, ogni volta che viene modificato un ramo "tag" e ogni volta viene modificato un ramo ramo "AUTOMATICO". In questo modo, i singoli sviluppatori possono utilizzare il sistema di CI con le loro filiali personali, un'importante capacità, IMHO.

    
risposta data 04.01.2012 - 20:41
fonte
0

Penso che tu intenda "cartella della documentazione". Organizzo i miei documenti per settore prima di tutto, dopo per cliente / applicazione, alla fine per "sviluppo e manutenzione".

Esempio: Progetti

  • Financial

    • Applicazione Web

      • Alfa app

         - source
         - functional docs
         - etc etc (testing, meeting with customer)
        
      • Beta dell'app

         - functional docs
         - etc etc (testing, meeting with customer)
        
    • Software desktop
  • Energia e amp; utilities
  • BLA BLA
risposta data 25.10.2010 - 23:04
fonte

Leggi altre domande sui tag