单独的“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中运行相同的代码,就像在野外一样。