是否可以使用单一配置，而不是将调试和发布分开（在我们的例子中）？

Question

我们为内部客户开发产品。我们没有 QA 团队，也不使用断言。性能很重要，但应用程序大小并不重要。

使用单一配置（而不是将调试和发布分开）是一个好主意，该配置将包含调试信息（pdb），并且还将进行性能优化？

这种方法有什么缺点吗？

Answer 1

两者都保留。有两种配置是有原因的！使用 Debug 版本进行调试，使用 Release 版本进行日常使用。

“合并”配置的缺点是显而易见的 - 您将无法通过干净的发布配置获得最佳优化，并且调试会很尴尬。以不同的配置重建项目所需的几秒钟（或几分钟）是值得的，相信我。

Answer 2

我想说的是，你应该始终将调试版本和发布版本分开。发布版本适用于您的客户，调试版本适用于您的开发人员。你说你不使用断言：也许你应该使用？即使您不在自己的代码中使用断言，您仍然可以在底层库代码中触发断言，例如，当使用无效迭代器时。这些将向开发人员发出警告，表明出现了问题。如果用户看到此消息：恐慌、致电技术支持、不执行任何操作，他们会怎么做？

调试版本可以为您提供额外的工具，以便在发布发布版本之前解决问题。您应该使用所有可用的工具来提高产品质量。

Answer 3

调试信息在优化构建中几乎毫无价值，因为优化器会将程序转换为无法识别的东西。此外，如果您有带有其他优化标志的辅助配置，则与未定义行为相关的错误更容易暴露。

Answer 4

调试和优化往往是相互矛盾的。编译器的优化通常会让调试变得很痛苦（函数可以内联、循环展开等），而使调试信息有价值的严格性束缚了编译器的双手，因此它也无法优化。基本上，如果将两者结合起来，那就是两全其美。

因此，成品的性能几乎要求它是“发布”版本，而不是调试版本，当然也不是两者的某种奇怪的混合。

Answer 5

你应该至少有两个。一个用于发布（性能），一个用于调试 - 或者您是否每次都第一次编写完美的代码？

Answer 6

单人可以吗
配置，而不是分离
调试和发布（在我们的例子中）？

可能没问题 - 这在很大程度上取决于您的情况（但根据您的详细信息，我认为这是非常不好的）。

我们没有 QA 团队，也不使用断言。

断言不是调试版本的问题。它们是您可以使用（或不使用）的另一种工具。

是否拥有 QA 团队不应该（严重）影响调试和发布版本之间的决定（但如果您确实有 QA 团队，迟早您可能会想要产品的调试版本）。

质量检查团队将严重影响产品的质量。如果没有专门的质量检查（由开发应用程序的人员以外的人进行），您就无法保证产品的质量或稳定性，也无法保证它能够完成预期的任务（或者它适合任何用途），并且您无法在很多方面对产品进行有意义的测量）。

也许您实际上不需要 QA 团队，但在大多数情况下，您只是剥夺了开发团队和客户（内部或外部）的大量必要数据。

调试版本应该可以更轻松地调试您的产品并跟踪问题并修复它们。如果您没有进行有组织的质量检查，您甚至可能不知道要解决的主要问题是什么。。

我认为您实际上有一个 QA 团队，只是您不这么认为：您的内部客户（甚至可能是您）是您的 QA 团队。就应用程序功能的重要性而言，这是一个坏主意。

与没有 QA 团队的合作就像自己制造一辆汽车并将其上路进行测试：您不知道车轮是否固定在一起，或者刹车是否有效，直到您进入交通。也许你不会杀死任何人，但我不会把你公司的关键数据放在你未经测试的应用程序中，除非它不是真的很关键。

性能很重要，应用程序大小并不重要。

如果性能很重要，那么谁来衡量它？测量代码是否属于您发布的应用程序？您是否在发布的代码中添加和删除它？

听起来您正在进行临时开发，并且使用性能关键的应用程序，没有 QA 团队，也没有专门的调试，我对您的团队是否能够真正交付有很多疑问。

我不知道你的情况，可能还有很多我看不到的地方，所以也许没关系。

这种方法有什么缺点吗？

是的：您要么最终在发布版本中得到诊断代码，要么必须在修复每个问题后删除诊断代码，并在处理下一个问题时再次添加它。

不过，您不应仅为了优化而删除调试版本。这不是一个有效的论点，因为您可以优化发布版本并保留调试版本不变。