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

14

Boa tarde

Gostaria de saber como vocês organizam as pastas do seu projeto?

Eu já fui um chefe que me sugere organizar por 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 organizar a tecnologia

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 projetos?

    
por Junior M 25.10.2010 / 22:43
fonte

6 respostas

6

Isso é 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

Temos usado essa estrutura para vários projetos com muitos clientes diferentes há anos e ela 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 nos permite ter contratados externos trabalhando em alguns projetos, mas não podendo acessar outros, já que podemos definir permissões na raiz do controle de versão.

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

Um grande benefício dessa estrutura é que você pode isolar o código dos clientes uns dos outros. Isso é útil se você precisar (a) enviar 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 com um projeto complexo que usa mais de uma tecnologia.

    
por 25.10.2010 / 23:54
fonte
8

Eu sou bem plana:

/ Projetos

Algumas variações chegam lá dependendo da caixa, mas por trás disso há muitas pastas individuais para projetos. Real deal vive no controle de origem de qualquer forma, por isso esta é apenas a casa local temporária.

    
por 25.10.2010 / 23:06
fonte
3

Eu tenho uma estrutura que se parece vagamente com o seguinte:

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

Archives contém projetos antigos em que não estou mais trabalhando. Work contém projetos relacionados ao trabalho. Current é tudo desenvolvimento atual. Em seguida, no meu diretório pessoal, eu faço o link simbólico de Projects para ~/Developer/Projects/Current . ~/Projects também inclui links simbólicos para alguns projetos de trabalho.

    
por 25.10.2010 / 22:59
fonte
3

Eu também tenho uma estrutura plana.

/ Projects

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 sobre a estrutura de pastas, pois muitos IDEs fornecem atalhos para projetos / arquivos recentes de qualquer maneira. E quantos projetos alguém trabalha de qualquer forma? Verdadeiramente, apenas por definição, os recentes.

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

/ Projects / Old_stuff

ou algo parecido. Eu arquivarei o que geralmente não estou trabalhando novamente.

    
por 26.10.2010 / 00:10
fonte
3

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

Nós estruturamos nossas ramificações de repositório; tags & 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 árvore de fontes propriamente dita, 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 ideia era (e ainda é) usar a estrutura do repositório para ajudar a estruturar a comunicação entre a equipe de engenharia; a parte voltada para o cliente do negócio e várias outras partes interessadas & especialistas de domínio.

A saber: documentos de origem que estão em um dos diretórios de "projeto" são usados (e ganham dinheiro) apenas uma vez. Os documentos que estão em um dos diretórios "productLines" ganham dinheiro quantas vezes um produto dessa determinada linha for vendido. Os documentos que ficam em um dos diretórios de "bibliotecas" ganham dinheiro tantas vezes quantas os produtos que os usam vendidos.

Torna explícita a noção de amortização de custos e ajuda a criar suporte para a reutilização de documentos de origem em toda a empresa.

Em um mundo ideal, o cliente que faz parte do negócio também usaria essa estrutura para armazenar apresentações & outras garantias de vendas, para que os desenvolvedores possam ver quais expectativas do cliente foram criadas, junto com o diretório de produtos relevante, e os colegas que lidam com clientes podem acompanhar o progresso do desenvolvimento dos recursos e produtos que 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 fontes procurando por pastas "compilar", dentro das quais eles localizam arquivos de configuração especificando como cada componente deve ser construído; um processo similar acontece para 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ídas da mesma maneira.

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

    
por 04.01.2012 / 20:41
fonte
0

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

Exemplo: Projetos

  • Financeiro

    • Aplicativo da Web

      • App Alpha

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

         - functional docs
         - etc etc (testing, meeting with customer)
        
    • Software de área de trabalho
  • Energia & utilitários
  • BLA BLA
por 25.10.2010 / 23:04
fonte