Como você organiza suas pastas de projetos? [fechadas]

Boa tarde

Gostaria de saber como vocês organizam suas pastas de projeto?

Eu já tive um chefe que me sugere organizar pelos Clientes.

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

Um amigo meu me disse para organizá-lo pela Technology

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

E você? Você tem uma maneira inteligente de organizar suas pastas de projeto?

Isto é o que estamos 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

Estamos usando essa estrutura para vários projetos com muitos clientes diferentes há anos e funciona muito bem.

É muito semelhante à sua sugestão inicial, mas usamos o controle de versão para gerenciar o controle de versão. Os repositórios do servidor são nomeados como "Cliente X - Projeto Y", em vez de qualquer outra coisa. Isso permite que contratados externos trabalhem em alguns projetos, mas não possam acessar outros, pois podemos definir permissões na raiz do controle de versão.

Todos fazem check-out de suas cópias de trabalho para onde quiserem em sua máquina de desenvolvimento (Windows) e usam o comando SUBST para mapear uma letra de unidade para esse local. Dessa forma, podemos ter caminhos relativos codificados em arquivos de construção, etc., que funcionam na configuração de todos. Assim, por exemplo, podemos ter links para bibliotecas compartilhadas, se assim o desejarmos. Geralmente, usamos links / aliases de controle de versão para fazer isso.

Um grande benefício dessa estrutura é que você pode isolar o código dos clientes. Isso é útil se você precisar (a) enviar a eles atualizações regulares da fonte para fins de integração, (b) ter contratados externos trabalhando em partes selecionadas do código.

Sua segunda sugestão não funcionará tão bem em um projeto complexo que usa mais de uma tecnologia.

Eu sou bem plana:

/ Projetos

Alguma variação chegando lá, dependendo da caixa, mas por trás disso existem muitas pastas individuais para projetos. O negócio real vive no controle da fonte de qualquer maneira, então essa é apenas a casa local temporária.

Eu tenho uma estrutura que se parece com a seguinte:

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

Archivescontém projetos antigos nos quais não estou mais trabalhando. Workcontém projetos relacionados ao trabalho. Currenté todo o desenvolvimento atual. Em seguida, no meu diretório pessoal, faço o link Projectspara ~/Developer/Projects/Current. ~/Projectstambém inclui links simbólicos para alguns projetos de trabalho.

Eu também tenho uma estrutura plana.

/ Projetos

Concordando com Wyatt Barnett, o negócio real vive no controle da fonte de qualquer maneira.

Só quero acrescentar que não deve haver nada de especial na estrutura de pastas, pois muitos IDEs fornecem atalhos para projetos / arquivos recentes. E em quantos projetos alguém trabalha? Verdadeiramente, apenas por definição, os recentes.

Além disso, apenas adiciono projetos recentes à pasta de nível superior. Arquivo todas as coisas antigas e concluídas em:

/ Projetos / Old_stuff

ou algo assim. Arquivo o que geralmente não voltarei a trabalhar.

No passado, eu usei repositórios do Subversion para armazenar meus documentos de origem e segui a convenção "projeto menor" para organização de repositórios, que eu achei que funcionava muito bem para organizações grandes e pequenas.

Estruturaríamos nossas ramificações do repositório; tags e tronco da seguinte forma:

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

Dentro da própria árvore de origem, usaríamos (algo como) a seguinte estrutura:

  (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

A idéia era (e ainda é) usar a estrutura do repositório para ajudar a estruturar a comunicação entre a equipe de engenharia; a parte do negócio voltada para o cliente e vários outros interessados ​​e especialistas em domínio.

A saber: os documentos de origem que estão em um dos diretórios "projeto" são usados ​​(e ganham dinheiro) apenas uma vez. Os documentos que ficam em um dos diretórios "productLines" ganham dinheiro quantas vezes um produto dessa linha específica é vendido. Os documentos que ficam em um dos diretórios "bibliotecas" ganham dinheiro tantas vezes quanto qualquer produto que os utiliza é vendido.

Isso torna explícita a noção de amortização de custos e ajuda a criar suporte para a reutilização de documentos de origem nos negócios.

Em um mundo ideal, o cliente que enfrenta parte da empresa também usaria essa estrutura para armazenar apresentações e outras garantias de vendas, para que os desenvolvedores possam ver quais expectativas do cliente foram criadas, ao lado do diretório de produtos relevante, e os colegas que acompanham o cliente podem acompanhar o desenvolvimento progresso nos recursos e produtos que eles estão vendendo.

Isso também significa que existe uma estrutura comum sobre a qual nossas ferramentas de automação de construção podem operar. (Nossos scripts de construção percorrem a árvore de origem procurando pastas "construídas" nas quais eles encontram arquivos de configuração que especificam como cada componente deve ser construído; um processo semelhante ocorre para a geração e teste de documentação). Novamente, em um mundo ideal, o site da organização e outras garantias de marketing poderiam ser construídos da mesma maneira.

Como uma nota final; o sistema de integração contínua sabe que precisa acionar uma compilação; análise estática; teste de fumaça e teste de unidade sempre que o tronco é modificado, toda vez que qualquer ramificação "tag" é modificada e cada vez que qualquer ramificação "AUTOMATED" é modificada. Dessa forma, desenvolvedores individuais podem usar o sistema de IC com suas ramificações pessoais, um recurso importante, o IMHO.

Eu acho que você quer dizer "pasta de documentação". Organizo meus documentos para o setor primeiro, depois para o cliente / aplicativo e no final para "desenvolvimento e manutenção".

Exemplo: Projetos

• Financeiro

  • Aplicação web

    • App Alpha

       - source
       - functional docs
       - etc etc (testing, meeting with customer)
      

    • App Beta

       - functional docs
       - etc etc (testing, meeting with customer)
      

  • Software para desktop
• Energia e utilidades
• BLA BLA