在Delphi中建立一个大型软件系统

Question

我们有一个大约16岁的软件包。几乎每个版本的Delphi（除了.NET版本）都经历过。多年来，当涉及到交叉引用并为其他软件包（如第三方库）保持正确的设置时，事情变得非常混乱。我想知道是否有一些标准练习来保持像这样有组织的大型项目（和项目组）。

所以解释当前的设置......

这是一个多应用系统。意思是，涉及12个可执行项目（以及一些DLL和服务项目）。我们还将事物保存在SourceSafe中，并且多个开发人员在不同的计算机上处​​理相同的代码。所有这些项目都被更多地转移到中央文件夹中。 “Root”文件夹包含 THE 主要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文件中项目所需的每个单元。

如果您确实使用了搜索路径，那么您就无法使用变体项目。例如，假设您有一个客户端发现了您在2年前发布的软件版本中的错误。您希望通过发布升级到该软件的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中设置了一个环境变量（即MRJ），指向“General \ Components \ Delphi”，因此在项目的选项中，我们将组件的路径声明为$(MRJ)\MadCollection\2.6.0.0。

General包含我们项目使用的IDE插件和组件。我们保留所有用于源代码管理的版本。这样，当我不得不切换回旧版本来追踪问题时，我可以简单地将其拉出并构建它，因为它的库路径仍将指向此特定版本所需的组件版本。

特定工作分支（Acceptance或其中一个子分支）中的文件夹组织遵循以下模式：

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. 使用MODERN类型的版本控制。我推荐Mercurial而不是其他人。 Source Safe是垃圾，不再使用它。

3. 备份环境（导出注册表项等）并以标准化方式将其还原到其他开发人员PC。您可以保留一些.reg和.cmd（批处理）文件来自动设置新系统。您可以将这些脚本放在版本控制系统的组件存储库中。

Answer 4

在以前主要讨论的范围之外，我建议：

• 单元测试 - 以DUnit为例
• 持续集成。只是为了确保所有这些项目都可以在另一台机器上编译，并且测试是可以的。

因此，这与项目组织和VCS战略密切相关。

Answer 5

对于类似的设置，我工作的公司发现此配置很有用：

• 所有第三方库（组件等）都转到固定位置（C：\ Delphi \ name-version）
• Delphi项目可以从任何地方的版本控制中检出（驱动器C：或D：和文件夹名称无关紧要），因为所有项目和脚本都使用相对路径
• 所有项目都是一个主项目文件夹的子文件夹，因此检查这个项目会将Delphi项目和其他相关资源带到工作站，并且版本控制更新很容易做到。
• 我们使用位于主文件夹中的构建脚本（用Apache Ant编写），并遍历所有文件夹以构建Delphi应用程序和运行单元和集成测试针对开发数据库服务器，在签入源代码管理之前验证所有更改是否有效
• 构建脚本也可以在每次提交时在构建服务器（Hudson CI）上自动运行，以查看是否存在问题

关于组件库的说明：避免软件包安装，更喜欢在运行时创建组件。如果您很快需要对五年前的项目版本应用修复程序，卸载/安装十几个软件包可能会令人沮丧。至少对于非可视组件，运行时创建可以节省大量时间。

检查源代码管理中的第三方代码可能非常有用，例如，共享尚未作为新官方发行版提供的修补程序。 Subversion文档章节 Vendor Branches 中介绍了最佳做法。 另外，使用Subversion，您可以使用 svn：externals 将特定版本（标记）放入项目目录结构中。这可以与第三方库和您自己的源代码一起使用，并使依赖管理更容易，工作站设置更容易。

P.S。 Ant构建脚本定义了所有内容的搜索路径，因此它是所有开发人员如何配置IDE，在何处放置第三方库以及使用哪些编译器标志的“参考”

p.p.s。你的项目听起来很有趣 - 我愿意接受合同工作：）

Answer 6

我的团队使用虚拟化，当我们回头看时，这是一个非常好的举措。 我们使用MacBook Pro笔记本电脑和VmWare Fusion，但我确信其他软件包也可以像VirtualBox或VirtualPC一样正常工作。

了解当新开发人员启动或旧安装遇到问题时，只需从主映像复制新的VM映像，并且设置完全，这总是一种很好的感觉。原版的。主映像存储在快速USB2磁盘上。现在，当Thunderbolt和USB3即将推出时，复制图像会更快。只要有记忆，现代计算机上的性能就没有真正的问题。 8 GB应该足以并行运行2个图像。虚拟化的另一个优点是可以轻松尝试如果场景。尝试不同的配置和版本，没有任何风险干扰真实的工作环境。

顺便说一下，我也认为SourceSafe是废话......： - ）

Answer 7

Somé提示：

• 为属于该项目的所有应用制作一个groupproject文件，每个应用在其自己的目录下的groupproj文件

• 您应该能够指定要包含在版本控制系统中的文件类型。确保将Delphi设置为以文本格式编写DFM文件。

• 您可以告诉Delphi在每个app下的'dcu'子目录中输出DCU（减少签证杂乱）。

• 第三方的东西经常坚持在不同的地方安装，你可以做的事情并不多。制作一份文档，描述如何设置完整的工作环境并使其保持最新状态

• 开发虚拟机。新开发人员会获得VM的副本。

• 维护不同的Delphi版本？反思，尝试去一个版本。如果每个版本绝对必须有两个groupprojects和目录结构。 [我假设你没有使用两个Delphi版本编译相同的应用程序，那是开发人员地狱]

• Delphi XE2将输出到不同的32/64子目录，这应该没有问题。