在Delphi中建立大型软件系统

Question

我们有一个有16年历史的软件包。它几乎通过了每个版本的德尔菲(除了.NET )。多年来，当涉及到交叉引用和为其他包(比如第三方库)保持适当的设置时，事情变得非常混乱。我想知道是否有一些标准的做法，当涉及到保持这样的大型项目(和项目组)这样的组织。

为了解释当前的设置..。

这是一个多应用系统。也就是说，涉及12个可执行项目(以及一些DLL和服务项目)。我们还保存在SourceSafe中，多个开发人员在不同的计算机上使用相同的代码。所有这些项目更多的是被抛到一个中央文件夹中。“根”文件夹包含主要的EXE项目(以及大约20个文件夹，所有文件夹都包含单位和表单)，它似乎是一个无尽的文件夹和文件层次结构。仅这一个项目就涉及50万行代码。

那么，所有其他应用程序都不一定与这个主要项目正确地分离开来。在主项目的根中，每个项目都有自己的文件夹。

我关心的两个主要问题是：

• 如何正确设置DCU文件，使它们不与项目混在一起？不应将DCU放在SourceSafe (以及任何类似的文件中)或其他任何从项目编译的文件中。Visual SourceSafe使文件在未签出时只读，并且在这种情况下无法将DCU文件(和EXE文件等)写入其中。那么，如何正确地将任何这样的文件分离到一个远程位置，以避免与源代码的任何混合？
• 如何正确设置包和库？我们有以下内容：
  • QuickReports 5.05
  • NativeJpg库V302 -
  • 另一个匿名报告库
  • 我们自己的组件包，它需要QuickReports、NativeJpg和其他匿名库。

​

所有4个库都存储在每台计算机的完全不同的位置，需要一些集中化。设置每个新开发人员的计算机的最大困难是从开发人员的计算机中找到这些计算机，并将它们复制到彼此计算机上的相同位置(并确保库路径正确，等等)。

我们还需要在同一台计算机上为不同版本的Delphi保留完全独立的环境。这意味着每台计算机上的项目的副本，每台计算机上的包和库的副本，SourceSafe中的项目、包和库的副本，等等。每台计算机都需要一个相同的设置。我们已经使用环境变量来指导我们的项目在哪里查找特定的项目文件(和库)。

另一个新的关注点是: XE2引入了64位功能。我们还没有计划对64位编译，但我们肯定会在未来。在所有这些项目中，我如何正确区分32位和64位？

我真正想要的是一个关于如何优化这样一个环境并使其组织得最好的好教程。我不希望任何人花时间回答所有这些问题。这些项目有超过15年的历史，有来自世界各地的200+开发人员的手，并且在项目之间有很多交叉参照。例如，一个项目可能使用来自另一个项目的单元，反之亦然。我个人不喜欢这个概念，但我也没有开始设计它。我的任务是组织这个系统，并详细记录如何在一台新电脑上设置Delphi，让新开发人员在我们的项目中工作。当我查看我们的项目时(因为我不一定是系统的开发人员，但正在被卷入开发中)，我看到代码的组织方式有很多混乱。

我假设Embarcadero可能有一些关于建立这样一个环境的准则和标准？

Answer 1

DCU文件的位置

对于编译过程的输出DCU，您应该在每个项目文件中指定一个DCU输出目录。在Delphi的最新版本中，默认值为.\$(Platform)\$(Config)。这将导致项目目录的子文件夹如下：Win32\DEBUG或Win64\RELEASE。

如果使用选项集设置项目文件，则可以从少量的选项文件中控制此设置(以及所有其他设置)。

第三方代码定位

您应该始终使用第三方库作为代码。如果供应商收取更多的费用作为代码接收库，则支付。一旦您这样做了，您只需将源代码包含到您的版本控制系统(VCS)中，并以与处理您自己的代码大致相同的方式对待它。我这么说主要是因为你应该避免修改它。

一旦您在VCS中拥有了所有代码，那么您就可以通过一次签出操作将整个源代码放到一台新机器上。

组织你的项目

我个人对使用编译器搜索路径有强烈的厌恶。我不使用它们，并在.dpr文件中包含项目中所需的每个单元。

如果您确实使用了搜索路径，那么您就不可能在变体projects.So上工作--例如，假设您有一个客户端在您两年前发布的软件版本中发现了一个bug。您希望通过发布对该软件2年前版本的升级来解决该漏洞。要求他们升级到最新版本是不可行的，这是完全合理的。也许他们还没有支付升级费用。也许整个升级带来了他们现在不想解决的重大变化。最好的例子是所有仍在使用Delphi 7的Delphi开发人员。

现在，在激发了这个场景之后，您将如何为这个2年前的项目创建一个构建环境？如果您正在使用搜索路径，那么它们将引用今天的库。您将被迫更改搜索路径，或者将旧库复制到当前库的顶部。

如果不使用搜索路径，并将所有源都包含在VCS中，那么整个头痛就显得微不足道了。

您的目标应该是能够检出您的程序的任何历史版本，并让它立即构建。您应该能够完全相信您正在构建与版本发布时所构建的相同的软件。这也要求您具有构建自动化，但我无法想象，您缺少这样一个规模的项目。

Answer 2

我去找文件夹组织。这来自一个软件套件，它有50+ exe和dll，还有很多第三方库，所以我想我知道你来自哪里……

我们使用Perforce作为源代码管理系统，因此我默认工作区的根文件夹名为Perforce，但我还设置了其他两个工作区，它们位于Perforce2、Perforce3等中。

常规文件夹设置(从工作区根文件夹开始)

General
  Components
    Delphi
      Indy
        Indy9
        Indy10
      MadCollection
        v2.5.8.0
        v2.6.0.0
  Plugins
Releases
  Released
  ... a folder for each release we publish ... (and equal to a branch in Perforce)
Work
  Acceptance
  Sub1
  Sub2

IDE中的“我的环境库”路径是空的(甚至没有BDE标准路径)。这可以确保项目的路径声明所有所需的路径，并且项目不依赖于特定机器的IDE设置。

我们在IDE中设置了一个环境var (即MRJ)，指向"General\ components \Delphi“，因此在项目的选项中，我们将组件的路径声明为$(MRJ)\MadCollection\2.6.0.0。

General持有IDE插件和我们的项目使用的组件。我们保留在源代码管理中使用的所有版本。这样，当我必须切换回一个旧版本来跟踪一个问题时，我可以简单地提取它并构建它，因为它的库路径仍然指向这个特定版本所需要的组件的版本。

特定工作分支中文件夹的组织(接受或其分支之一)遵循以下模式：

General          
  Includes
  MainComponent1
    Project1
    Project2
    Shared
  MainComponent2  
    Project3
    Project4
    Shared
  Shared
Windows          
  SoftwareSuite  
    Scripts
      Tools
  MainComponent1
    Project1
      Dcus
    Project2
      Dcus
  MainComponent2  
  Tools
    Tool1
      Dcus
    Tool2
      Dcus

通用文件夹保存所有独立于平台的源/文件，Windows文件夹保存所有Windows特定的文件。每个组件可以保存多个项目，并将有一个共享文件夹，用于在这些项目之间共享资源。共享文件夹直接位于General下，保存所有项目共享的资源。Windows文件夹的设置方式与此类似。

注意，每个项目都有自己的dcus文件夹。这是在项目选项中配置的。由于路径可以输入为.dcus，所以我们(至少我)将此设置为任何新项目的默认设置。每个项目将其dcus发送到一个唯一的文件夹，可以确保两件事：

• 通过在您的版本控制软件中设置一个过滤器，可以很容易地将dcu排除在版本控制之外。
• 更重要的是，它确保项目的编译/构建不会干扰对另一个项目的编译/构建。我可以安全地更改设置和构建，知道我不会被来自另一个项目的先前构建的dcu所困扰。

Answer 3

我建议以下做法：

1. 保持库路径简单，并确保库路径中的所有内容要么是随delphi附带的文件夹，要么是d:\Components\文件夹中的DCU二进制(库)文件夹。
2. 使用现代版本控制类型。我推荐“变化莫测”。来源安全是垃圾，别再用了。
3. 备份您的环境(导出注册表项等)，并以标准化的方式将其还原到其他开发人员PC上。您可以保留一些.reg和.cmd (批处理)文件，以便自动设置新系统。您可以将这些脚本放在版本控制系统中的组件存储库中。