对抗发布产品中的调试代码

Question

我在一家非常小的初创开发商店（3 名开发人员）工作，经常被从我正在从事的工作中抽离出来，以修复关键任务错误或实现“绝对关键”的软件功能 - 我的错误列表被重新优先考虑几乎每天都会发生，我很少知道几个小时后什么会是“重要的”。

正因为如此，我发现我对添加可能未经我们 QA 部门（阅读：人）检查的代码变得越来越谨慎。

当我实现一个新函数时，不知道是否会在任何时候被调用，我有时会尝试在顶部编写一个 return 语句，以确保代码永远不会在发布版本中执行。

像这样的语句的问题

public void NewFunction()
{
    return; // Put break point so that I can use the debugger to step to meat:

    meat:
    // ... More code
}

是，即使在调试模式下，Visual Studio 也足够聪明，知道肉类：永远不会被执行，所以你不能对肉类使用“设置下一个语句”命令。将代码包装在#if !DEBUG 等编译器指令中也是如此。

相反，我会写这样的内容：

public void NewFunction()
{
    if("a"[0]=='a')
        return; // put break point here

    meat:
    // ... More code
}

这样，如果此代码意外滑入发行版，也不会造成任何损害，但因为直到运行时才对其进行评估，所以我可以使用调试器逐步解决问题：没有问题。

我真的不喜欢让事情未完成，但在关键时刻我们常常没有时间搁置变更集或正确地做事情。目前，通过 API 访问未完成的功能（如上面概述的功能）并不是一个问题，因此我认为将它们保留在软件中不会立即造成任何损害（但最终，它们可能会导致在使用过程中出现一些糟糕的时刻）维护 - 就像“wtf 这个函数在这里什么都不做吗？因为我不记得 6 个月后我在做什么”。

考虑到我（不幸的是）半定期地做这样的事情，这个问题有标准做法吗？作为一个更大的问题，是否有一些实践可以帮助解决一般软件版本中的调试代码？

Answer 1

有几件事对我来说很突出：

• “我真的不喜欢让事情未完成”，
• “我有时会尝试在顶部编写一个 return 语句，只是为了确保代码永远不会在发布版本上执行。”
• “这样，如果这段代码不小心滑入版本中”，

我会查找一些敏捷方法和实践。它的设计目的是考虑到版本中快速移动的目标。

您应该执行以下操作：

• 确保所有新代码都有单元测试来支持其功能。
• 为您更改的代码编写单元测试，以确保您更改的内容不会破坏现有功能。
• 使用 Cruise Control 或类似产品执行连续构建。这与测试一起让您在出现问题时立即知道。
• 开始按功能/任务进行分支，这样就不会“意外”出现代码。在所有代码的主线之外工作，即使您从一个优先任务转移到另一个优先任务也会导致这些失误。
• 产品应该始终有效。在任何时间点，只要产品中完成了 X 个功能，它就应该可以工作。不要半途而废地实现某个功能。将其分解为可以说有效的更小的功能和任务。即使客户永远不会使用它们也没关系。这可以防止未完成的功能被其他开发人员使用并破坏。
• 修复破损的窗户。不要让非常糟糕的设计或错误继续存在。这只会使问题变得更加复杂。

通过遵循任务/功能分支，您不必创建将像问题中那样签入的中间代码。那不应该发生。如果您切换将在另一个分支中的任务。使您的流程最小化，并且您的分支毫不费力。那么这些事情就会成为第二天性。

Answer 2

假设您的代码是 C# 语言，您可以使用 [Conditional ] 属性来排除 Release 配置中的某些方法调用：

[Conditional("DEBUG")]
public void NewFunction (object something)
{
    // do something
}

这相当于将方法本身及其所有调用包装到 #if DEBUG / #endif 条款。

当未定义 DEBUG 符号时，任何对 NewFunction 的调用都将被编译器排除。控制它的最简单方法是通过 Visual Studio 中的解决方案和项目配置。在调试配置中，定义了DEBUG符号，这与释放配置相反。

请注意，只能排除 void 调用，因为代码不依赖于这些方法的返回值。

然而，这是设计用于跟踪、日志记录等。我不太明白你打算如何保留一些未完成的方法，但仍然在调试版本中使用它们。如果它们不起作用，那么调用它们有什么意义，或者如果它们起作用，为什么不将它们包含在发布中？

Answer 3

分布式版本控制系统使分支和合并变得轻而易举。使用像 Mercurial 这样的工具（我个人的偏好），您甚至不需要远程存储库 - 您只需在本地系统上就地创建存储库，然后将该存储库克隆到本地驱动器上的其他位置。因此，您可以轻松保留代码的“发布”版本，同时快速将代码更改迁移到“调试”分支或从“调试”分支迁移。

Answer 4

我也有同样的情况。我有时会在新函数的调用周围加上#IF DEBUG。或者#IF DEBUG 围绕函数的整个内容。

我做的另一件事是在函数上添加 TODO:Unit Test 注释，以便在发布时我可以搜索这些注释并知道是否存在问题。