您如何组织项目文件夹？[关闭]

下午好

我想知道你们如何组织您的项目文件夹？

我曾经有个老板建议我按客户组织。

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

我的一个朋友告诉我按技术组织时间

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

你呢？您有一种巧妙的方式来组织项目文件夹吗？

这就是我们一直在使用的：

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

多年来，我们一直将此结构用于具有许多不同客户的多个项目，并且效果很好。

这与您最初的建议非常相似，但是我们使用版本控制来管理版本控制。服务器存储库被命名为“客户X-项目Y”，而不是其他任何名称。这使我们可以让外部承包商在某些项目上工作，但无法访问其他承包商，因为我们可以在版本控制根目录下设置权限。

每个人都将工作副本检出到（Windows）开发人员机器上所需的任何位置，并使用SUBST命令将驱动器号映射到该位置。这样，我们就可以在构建文件等中使用硬编码的相对路径，这些路径可以在每个人的设置中使用。因此，例如，如果愿意，我们可以具有指向共享库的链接。我们通常使用版本控制链接/别名来实现这一目标。

这种结构的一大好处是，您可以将客户的代码相互隔离。如果您需要（a）向他们发送源代码的定期更新以进行集成，（b）让外部承包商来处理代码的选定部分，则这很有用。

您的第二个建议对于使用不止一种技术的复杂项目而言效果不佳。

我很平坦：

/项目

某些变化取决于框，但在其后只是项目的单个文件夹。无论如何，真正的交易生活在源代码控制中，因此这只是临时的本地住所。

我的结构大致如下所示：

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

Archives包含我不再从事的旧项目。Work包含与工作有关的项目。Current是所有当前的发展。然后，在主目录中，我链接Projects到~/Developer/Projects/Current。~/Projects还包括一些工作项目的符号链接。

我也有一个扁平的结构。

/项目

同意怀亚特·巴内特（Wyatt Barnett）的想法，无论如何，真正的交易还是生活在源代码控制中。

只是想补充一点，无论如何文件夹结构都不应该有什么特别之处，因为无论如何，许多IDE都提供了指向最新项目/文件的快捷方式。任何人都从事多少个项目？确实，仅根据定义，就是最近的。

另外，无论如何，我只会将最新项目添加到顶级文件夹中。我将所有较旧且完整的内容存档到：

/项目/旧材料

或类似的东西。我存档了通常不会再处理的内容。

过去，我曾使用Subversion信息库来存储我的源文档，并遵循了“子项目”约定来进行信息库组织，我发现这种约定对大型和小型组织都非常有效。

我们将构建存储库分支；标签和主干如下：

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

在实际的源代码树本身中，我们将使用（类似）以下结构：

  (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

这个想法曾经是（现在仍然是）使用存储库的结构来帮助工程团队之间进行结构化的沟通。业务中面向客户的部分以及其他利益相关者和领域专家。

举例来说：位于“项目”目录之一中的源文档只能使用一次（并赚钱）。位于“ productLines”目录之一中的文档的收入与该特定行中的产品被出售的次数相同。位于“图书馆”目录之一中的文档的收入是使用它们的任何产品售出的收入的多少倍。

它使费用摊销的概念变得明确，并有助于建立对整个企业中源文档重用的支持。

在理想的世界中，面向客户的业务部门也将使用此结构来存储演示文稿和其他销售抵押品，以便开发人员可以在相关产品目录旁边看到已创建的客户期望，并且面向客户的同事可以跟踪发展他们销售的功能和产品方面的进展。

这也意味着我们的构建自动化工具可以在一个通用的结构上运行。（我们的构建脚本会在源代码树中查找“ build”文件夹，在其中找到配置文件，这些文件指定了如何构建每个组件；用于文档生成和测试的过程类似。）同样，在理想情况下，可以以相同的方式构建组织的网站和其他营销材料。

最后一点：持续集成系统知道需要触发构建；静态分析；烟雾测试和单元测试在每次修改主干，每次修改任何“ tag”分支以及每次修改任何“ AUTOMATED”分支时进行。这样，单个开发人员便可以将CI系统及其个人分支（IMHO的一项重要功能）一起使用。

我认为您的意思是“文档文件夹”。我首先为部门组织文档，然后为客户/应用程序组织文档，最后为“开发和维护”组织文档。

示例：项目

• 金融

  • Web应用程序

    • 应用程式Alpha

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

    • 应用测试版

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

  • 桌面软件
• 能源与公用事业
• 布拉