单独的“debugging”和“发布”版本？
我认为最好是发布开发人员testing的软件版本。 因此，我倾向于从project / makefile中删除“debug”目标，这样只有一个版本可以被构build（并经过testing，debugging和发布）。
由于类似的原因，我不使用“断言”（请参阅断言总是不好的？ …）。
有一个人认为，“debugging”版本的原因是debugging更容易：但是我反驳说，最终你可能会支持和debugging你发布的任何东西，所以你需要构build一个版本你可以根据需要进行debugging…这可能意味着启用debugging符号，并禁用一些优化，即使在“发布”版本。
有人说“这是一个坏主意”; 这是我几年前发展起来的一个政策，
- 一些开发人员正在testing他们的debugging但不是发行版本
- 一些开发人员编写的bug只在发布版本中出现
- 该公司在testing不足之后发布发行版本（它是否完全足够？）
- 被调用来debugging发行版本
从那以后，我看到不止一个开发商遵循这种做法（即没有单独的debugging和发布版本）。
你的政策是什么？
这可能是微不足道的，但它加起来就是别人在这里所说的。 拥有QAtesting版本的优势之一是随着时间的推移，软件的内置debugging和loggingfunction将会因为开发人员的需求而得到提升，这些开发人员需要弄清楚QA中为什么会出现问题。
开发人员需要debugging的发行版本越多，那么当客户开始遇到问题时，您将会拥有更好的工具。 当然，作为开发周期的一部分，开发人员没有理由在开发版本上工作。
此外，我不知道有任何软件公司有足够长的周期来承担QA从debugging到版本testing期间中途发布版本的开销。 必须进行完整的质量保证周期是非常罕见的事情。
分开debugging和发布构build是一个好主意，因为它确实使开发更容易。
但是debugging版本只能用于开发，而不能用于testing。 你只testing发布版本。 而且你不使用开发人员来testing这些构build，你使用testing人员。
这是一个简单的政策，给两全其美，国际海事组织。
编辑：作为对评论的回应，我认为很明显，debugging和发布构build（可以）生成不同的代码。 认为“-DDEBUG”与“-DNDEBUG”和“#if defined（DEBUG）”等
因此，testing最终出货的代码至关重要。 如果您在debugging和发布版本中生成不同的代码，则意味着要进行两次testing – 不pipe是否由同一个人testing。
然而，debugging符号并不是什么大问题。 始终使用debugging符号构build，保留未被分离的二进制文件的副本，但释放已剥离的二进制文件。 只要你以某种方式标记每个二进制文件的内部编号，你应该始终能够识别哪个未被解压缩的二进制文件对应于你必须debugging的二进制文件。
如何从外部源去除二进制文件并在debugging器中加载符号取决于平台。
我们的政策是让开发人员在Debug版本上工作，但其他人（QA，BA，销售等）运行发布版本。 昨天，我不得不修复一个只在发布版本中出现的bug，显然发生了什么，只是因为它只是在发布
这是这家店的第一家，我在这里已经有18个月左右的时间了。
当发布版本对debugging版本做不同的事情的时候 – 是的，我去过地狱，并且看到了一些非常复杂的生产代码。
如果configuration之间的唯一区别是debugging符号和优化，我没有理由不这样做。
所以你需要build立一个版本，你可以在必要时进行debugging…这可能意味着启用debugging符号，并禁用一些优化，即使在“发布”版本。
嗯…这听起来像你正在做一个debugging版本给我…对不对？
你出错的部分是这样的陈述：
我认为最好是发布开发人员实际testing的软件版本
开发人员不testing代码。 testingtesting代码。
你的unit testing应该testing所有的构buildconfiguration。 不要让你的开发人员用一只手绑在背后 – 让他们使用他们在那里处理的所有debugging工具。 一个debugging版本是其中之一。
关于断言：断言的使用在很大程度上取决于你是否按合同编程。 如果这样做，那么断言只是在debugging版本中检查合同。
根据我在链接线程中的回答，我们也使用相同的构build进行debugging和发布的原因非常类似。 与algorithm级别的手动优化相比，优化器获得的10％-20％的性能提升往往非常小。 一个构build可以消除许多潜在的错误。 特别;
-
未初始化的variables和小的缓冲区溢出最终可能会在debugging和优化版本构build方面产生非常不同的结果。
-
即使有可用的符号信息，debugging优化的版本也很困难，因为对象与源不匹配，例如variables可能已被优化，代码可能已被重新排列。 因此，在testing版本构build中报告的错误可能会更加困难，因此需要花费很长时间才能追踪到。
在自动回归testing中比较了未优化和优化的版本，优化提供的性能收益并没有提供足够的额外价值，在我的情况下有两个版本。 值得注意的是，我开发的软件非常需要CPU（例如创build和操作大型表面模型）。
我认为这取决于项目大小以及您正在使用的构build系统和testing的types。
如果你有一个自动化的构build系统，并且在一个给定的构build上运行单元和functiontesting很简单，那么你应该永远不会遇到多个构buildtypes的问题。
我总是订阅“发送你debugging的东西，所以你可以debugging你发货的方式”，因为你列出了你的问题的所有原因。
用Java开发时，我讨厌非debugging版本。 当抛出一个exception时，你不会得到任何行信息，这使得很难甚至不可能跟踪错误。 此外，debugging和非debugging之间的运行时间差异与Java 5或更高版本是5％左右，所以这是真的没有问题，并与今天的硬盘，大小无所谓了。
在使用debugging版本的正面：
- 堆栈跟踪包含您需要的所有信息
- variables可以被检查
- 如果您在生产中遇到问题，则可以简单地连接到正在运行的进程，而无需先停止服务器以安装debugging版本。
- 你不会被聪明的优化错误所困扰
- 构build更简单（只是一个神器）
开发人员使用debugging版本，QA和其他人使用发布版本，我们称之为“生产”。 这样做的主要优点是在debugging版本中，我们可以添加大量额外的代码和断言。 有些对象包含额外的信息，除非在debugging器中查看代码，否则没有任何用处。 一些对象会定期validation自己，以确保所有状态信息一致。 这些东西使debugging版本慢得多，但是他们帮助我们find了在生产构build中找不到的错误的结束。
正如我所说，我们所有的质量保证和性能testing都使用生产版本，偶尔会遇到生产中出现的问题，而不是debugging中出现的问题。 但是它们相对比较less见，而作为开发者，debuggingdebugging版本而不是生产版本的优势远远超过了这个问题。
在我看来，这个讨论忽略了一个非常重要的观点：
这真的取决于它是什么样的项目！
如果你创build一个本地的（C / C ++）项目，你将会被迫创builddebugging版本，只是因为在某些情况下编译器优化可能使debugging几乎不可能。
如果您创buildWeb应用程序，您可能希望只需构build一个构build（尽pipe“构build”对于某些Web应用程序而言颇具误导性），可以在运行时启用日志loggingfunction。
虽然本地C ++项目和PHP Web应用程序显然不是所有types的项目，但我希望我的观点能够通过。
PS：在为C＃开发时，遇到了一个边界情况，因为虽然使用debugging版本会禁用编译器优化，但根据我的经验，您不会遇到与C ++差不多的差异
在这里我们开发debugging模式，并在发布模式下进行所有的unit testing。 我们是一个只有less数（12岁以下）应用程序的小店，支持从传统的ASP，ASP.Net，VB.Net和C＃。 我们也有一个专门的人来处理所有的testing，debugging过的问题被抛回给开发人员。
我们总是build立两个，甚至从来没有考虑不这样做。 启用debugging选项会增加您的代码大小并降低性能，testing时可能不是您的软件types的问题，但如果客户正在运行您的代码以及其他5个应用程序，则会发生什么情况？
testing问题可以通过使用自动化testing来进行分类，因此当您认为准备发布时，可以毫不费力地testing发布版本。 您的开发人员或公司无法正确testing发布版本，但在开发人员和公司的发布和debugging版本方面并不是一个失败。
在最后一点，我从来没有被要求debugging发布版本，只是为了解决它…
这是一个折衷。 考虑到CPU周期很便宜而且越来越便宜，而人力周期仍然很昂贵，所以维护一个庞大而复杂的程序 – debugging（山墙）版本的单一版本是很有意义的。
总是使用断言总是比从不使用断言更安全的策略。 如果生成单独的debugging版本和发行版本，请重新启用您需要的任何#define d符号，以确保在发行版本中启用了断言。
我认为权衡很简单：是的，只有一个发布版本，你真的testing实际发货。 另一方面，您为开发人员和/或用户的性能付出了一定的代价，所以最好由您来检查这两种情况。
在大多数大中型项目中，易于debugging将确保为用户提供更好的产品。
如果你有一个真正的QA团队可以完全testing这个东西，我会说make make build直到你接近release，然后确保一个完整的QA周期在同一个build上完成走出门外。
尽pipe至less在一个案例中我们发布了一些仍然有一些debugging代码的东西。 唯一的后果就是运行速度慢了一点，日志文件非常大。
在我的公司，我们有debugging和发布。 – 开发人员使用debugging版本来正确查找和修复错误。 – 我们使用TDD，所以我们有一个很大的testing套件，我们在我们的服务器上运行，testingdebugging和发布版本configuration，以及我们也有的64/32版本。
因此，如果使用“debugging”configuration可以帮助开发人员更快地发现错误，那么没有理由不使用它 – 当代码进入服务器（待进一步testing）或审查时，我们使用“发布”。
我学会了很久以前用.PDB文件构build发行版，以便我可以debugging发行版。 很多程序员往往会忘记的是，当你运行debugging版本时，所有的优化都被closures，你正在debugging一个不同的程序。 它的行为可能与发布版本（大部分）相似，但与发布版本相比，它仍然是一个不同的程序。
另外，debugging发布版本并不难。 如果你得到一个崩溃转储，你必须能够做到这一点。
看到这是什么是你最有争议的编程意见？
引用：
意见：“debugging”和“发布”版本之间永远不会有不同的代码
主要原因是释放代码几乎从来没有得到testing。 最好在testing中运行相同的代码，就像在野外一样。
