我认为最好发布您的开发人员实际测试过的软件版本；因此，我倾向于从项目/makefile 中删除“调试”目标，这样就只能构建（并测试、调试和发布）一个版本。
出于类似的原因，我不使用“断言”（另请参阅断言总是不好的吗？ ...).
那里的一个人认为“调试”版本的原因是它更容易调试：但是，我反驳说，您最终可能希望支持和调试您发布的任何内容，因此您需要构建一个版本如果需要，您可以进行调试...这可能意味着启用调试符号，并禁用某些优化，即使在“发布”版本中也是如此。
还有人说“这是一个坏主意”；这是我几年前制定的一项政策，曾被以下因素所困扰：
- 一些开发人员测试他们的调试版本而不是发布版本
- 一些开发人员的编写错误仅在发布版本中出现
- 该公司在测试不充分后发布了发布版本（是吗？ever完全足够了？）
- 被要求调试发布版本
从那时起，我看到不止一个其他开发商店遵循这种做法（即没有单独的调试和发布版本）。
你们的政策是什么？
单独的调试和发布版本是一个好主意，因为它确实使开发变得更容易。
但调试版本应该仅用于开发，而不是用于测试。您仅测试发布版本。而且您不使用开发人员来测试这些构建，而是使用测试人员。
在我看来，这是一个简单的政策，可以两全其美。
Edit:作为对评论的回应，我认为调试和发布版本显然可以生成不同的代码。想想“-DDEBUG”与“-DNDEBUG”和“#if Defined(DEBUG)”等。
因此，测试最终交付的代码至关重要。如果你do在调试和发布版本中生成不同的代码，这意味着测试两次 - 无论是否由同一个人测试。
然而，调试符号并不是一个大问题。始终使用调试符号进行构建，保留未剥离的二进制文件的副本，但释放剥离的二进制文件。只要您以某种方式用内部版本号标记每个二进制文件，您应该始终能够识别哪个未剥离的二进制文件对应于您必须调试的剥离的二进制文件...
如何从外部源中剥离二进制文件并在调试器中加载符号取决于平台。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
