如何将调试代码排除在产品之外?

It happens to the best of us.

这发生在我们当中最好的人身上。

Particularly when dealing with languages without built in debugging capabilities such as breakpoints and watched variables, these bugs bite developers. Debugging code, alerts and Response.Writes, show up in production code.

特别是在处理没有内置调试功能(如断点和监视的变量)的语言时，这些bug会让开发人员头疼。调试代码、警报和响应。写入，显示在产品代码中。

How do you separate debugging concerns from functional code in javascript, php, or vbscript? How do you ensure those debugging changes never enter production environments?

如何将调试关注点与javascript、php或vbscript中的函数代码分离?如何确保这些调试更改不会进入生产环境?

15 个解决方案

#1

It may not be perfect but I have a macro in my editor that allows me to add debug and wraps it in appropriate flagging comments. I also have a script that I run later that rips that stuff back out. Granted, it took me a while to really trust this mechanism but over time I've become comfortable with it.

它可能不是完美的，但是我的编辑器中有一个宏，它允许我添加调试，并将其封装在适当的标记注释中。我也有一个脚本，我在后面运行，它会把那些东西撕下来。当然，我花了一段时间才真正相信这种机制，但随着时间的推移，我已经习惯了。

My preference is avoid ever checking in debug code. Obviously as with any other 'rule' there are exceptions to this, but because it's easy to miss things later, I don't like checking it in.

我的偏好是避免检入调试代码。显然，与任何其他“规则”一样，这个规则也有例外，但因为以后很容易遗漏，所以我不喜欢检入它。

#2

The most simple method

最简单的方法

define("DEBUG", true);


if (DEBUG) {
    echo "Debug Method";
}

For js its similar.

js的相似。

#3

Human error is hard to prevent

人的错误是很难避免的

https://meta.stackexchange.com/questions/71780/lol-debugging-are-we-so-homepage-alerts-false

https://meta.stackexchange.com/questions/71780/lol-debugging-are-we-so-homepage-alerts-false

#4

There are several ways to hide debug code in production, but few to remove it (when a compiler cannot automatically remove it).

有几种方法可以在产品中隐藏调试代码，但是很少有方法可以删除它(当编译器不能自动删除它时)。

I hide debug code by:

我隐藏调试代码如下:

• Only displaying it when the logged in user is a developer or tester.
• 只有当登录用户是开发人员或测试人员时才显示它。
• Outputting it to a log/database when server side.
• 在服务器端将其输出到日志/数据库。

I remove it by searching for special comments before deployment:

在部署前，我通过搜索特殊的注释删除它:

• alert("false") //TODO:REMOVE DEBUG CODE
• 警报(“false”)/ / TODO:删除调试代码

My coworkers also suggested:

我的同事还建议:

• Overriding alert to check for a debug variable. (Side effects?)
• 覆盖警报以检查调试变量。(副作用?)
• Writing a alertDebug method to check for a debug variable. (Will anyone remember it?)
• 编写一个alertDebug方法来检查一个调试变量。(会有人记得吗?)

• Checking to see if firebug was running

  检查firebug是否正在运行

  if(window.console && window.console.firebug) { alert("you are using firebug"); }

  如果窗口。控制台和windows .console.firebug) {alert(“您正在使用firebug”);}

#5

One method is with an environmental variable. In your server configuration, you could set an environmental variable to say debug or not. The production servers would be configured to false, and the development to true. That way all you do in the code is check the environmental variable:

一种方法是使用环境变量。在您的服务器配置中，您可以设置一个环境变量来表示调试。生产服务器将被配置为false，开发将被配置为true。这样你在代码中所做的就是检查环境变量:

In PHP:

在PHP中:

if (getenv('DEBUG_MODE')) {
    var_dump($foo);
}

That way, there's no way to forget, since it'll automatically turn itself off. But if you REALLY need to turn it on in production, just flip the switch...

这样的话，你就不会忘记它了，因为它会自动关闭。但是如果你真的需要在生产中打开它，只要打开开关……

• Docs for Apache
• 对Apache文档
• Docs for Lighttpd
• 文档的Lighttpd
• Docs for NginX
• NginX的文档

#6

As the most poular answer has a security flaw, let me include a less risky version from php.net.

由于大多数poular的答案都有一个安全漏洞，让我在php.net中加入一个风险更小的版本。

define ('DEBUG', 1);

if (DEBUG == 1) {
   // echo some sensitive data.
}

The basics are the same, but this one won't execute debug code if the constant DEBUG is undeclared.

基本原理是一样的，但是如果常量调试是未声明的，那么这个不会执行调试代码。

The problem with if (DEBUG) is that if the constant is not defined it will assume the string "DEBUG" which evaluates to true.

if (DEBUG)的问题是，如果常量没有定义，它将假设计算结果为true的字符串“DEBUG”。

#7

Code reviews. Generally when someone looks over the code this sort of thing really sticks out.

代码评审。一般情况下，当有人查看代码时，这类东西会非常突出。

#8

Here we have multiple stages of testing before code ever reaches production. Different groups of testers at each stage with different goals. Seems to work so far (we've never had debug code like this get out to production).

在这里，在代码投入生产之前，我们有多个测试阶段。每个阶段不同的测试人员组有不同的目标。到目前为止似乎还能工作(我们从未有过这样的调试代码发布到产品中)。

I was going to say "code reviews" but everyone else already said that, and I'm not sure it would have caught something like this...

我想说“代码评审”，但其他人都已经说过了，我不确定它会捕捉到这样的东西……

#9

It tends to happen less if you utilize language features which are designated for debugging purposes:

如果您使用指定用于调试目的的语言特性，那么发生这种情况的可能性会更小:

 assert( is_string($param1) );

Does not hurt production code.

不影响生产代码。

#10

what i do is in php

我用的是php

define ("DEBUG", true);


function op (){
    if ( !DEBUG ) return true;

    $args = func_get_args();

    foreach ( $args as $var ){
        if ( is_object ( $var ) or is_array ( $var ) ){
            print "<br /><pre>";
            print_r ( $var );
            print "</pre>";

        }
        else{
            print "<br />" . $var;
        }
    }

        return true;
}

// On places to check 
op ($array, $var);

In js also i will do the same like

在js中，我也会这样做

function calert(message){
    if (!debug) return;
    alert (message);
}

#11

Are you working on production server directly? Do you ever heard of staging server or test server? You can use your own computer to became your stage server-- use microsoft web matrix! Make your code clean and working perfectly there and then move to production.

您是否直接在生产服务器上工作?您听说过登台服务器或测试服务器吗?您可以使用您自己的计算机成为您的舞台服务器——使用微软网络矩阵!使您的代码保持干净，并在其中完美地工作，然后转向生产。

There is no other good way to make sure that debugging code pop up on production server--QA before production

没有其他好的方法可以确保调试代码在生产服务器上弹出——生产前的QA

#12

I follow three rules for debug code

我为调试代码遵循三个规则

Make the source code look awful, by...

使源代码看起来很糟糕，通过…

 not indenting it from the left margin

 egregiously violating the coding standard

 putting in extra whitespace above and below

Set up a global debug switch, and

设置一个全局调试开关

 have it alter an obvious output if it is ON, and

 make the debug code compilation depend on that switch being ON (i.e., so the code won't compile if the global switch is OFF)

Sabotage an obvious output, such as by:

破坏明显的输出，例如:

 delete something really important

 put up 99/99/99, for the date

 comment out the "File Load" function

 delaying the splash-screen

 etc.

These three rules have worked well for me.

这三条规则对我很管用。

#13

I am only going to mention this, since nobody has gone there.

我只想提一下，因为没有人去过那里。

If you don't write any debug code, then debug code won't make it to production.

如果您不编写任何调试代码，那么调试代码将无法投入生产。

If you are writing "debug code", it suggests that you don't actually understand your code well. Maybe it is too complex.

如果您正在编写“调试代码”，这表明您实际上并不理解您的代码。也许它太复杂了。

Write your unit tests first. That practice will lead to better design. Make sure you have complete code coverage. Test the cases that are hard to make happen - can't get a socket connection, database is not available, etc. Write regression tests. Do not deploy anything that can't pass them. Any bug report should be turned into a regression test before the code is changed. The regression test should fail - and be the only test that fails. Fix the bug.

首先编写单元测试。这种实践将导致更好的设计。确保您有完整的代码覆盖。测试难以实现的情况——无法获得套接字连接、数据库不可用等等。编写回归测试。不要部署任何不能传递它们的东西。在修改代码之前，应该将任何错误报告转换为回归测试。回归测试应该失败——并且是唯一失败的测试。修复bug。

Automate the compilation and testing. If you actually write debug code, it should be removed immediately after testing is successful. When your organization is really mature, perhaps you will even automate deployment.

自动编译和测试。如果您确实编写了调试代码，那么应该在测试成功之后立即删除它。当您的组织真正成熟时，您甚至可能会自动部署。

#14

My recommended way of debugging PHP code even in production mode.

我推荐的在生产模式下调试PHP代码的方法。

1. Sign up for free and create an app at http://todell.com/debug

   注册免费并在http://todell.com/debug中创建一个应用程序。

2. Debug your php code like this

   像这样调试php代码。

   define("DEBUG_LVL",1); /*place this anywhere convenient to edit or on a single file that was included in your entire web application. */

   定义(“DEBUG_LVL ",1);/*把它放在任何方便编辑的地方，或者放在包含在整个web应用程序中的单个文件上。* /

   if(DEBUG_LVL > 0) file_get_contents("http://todell.com/w/y///".urlencode(json_encode($object))."/".LINE."/".urlencode(FILE)."/".$_SERVER["REMOTE_ADDR"]);

   如果(DEBUG_LVL > 0)file_get_contents(" http://todell.com/w/y/// " .urlencode(json_encode(对象)美元)。“/”.LINE。“/”.urlencode _SERVER(文件)“/”。[" REMOTE_ADDR "]);

Where $object is the object you want to send to your debug app. it can be anything from exception thrown from your code or a benchmarking data. The $object size limit is 64KB This is not limited for PHP language only.

$object是要发送到调试应用程序的对象，它可以是代码抛出的异常，也可以是基准测试数据。$对象大小的限制是64KB，这并不仅限于PHP语言。

#15

Developer diligence and good testers are all that stands in the way, really. There's no single tool or process that can prevent such things from happening.

开发人员的勤奋和优秀的测试人员才是真正的阻碍。没有单一的工具或过程可以阻止这种事情发生。

If anything, it's a prime example of why it's critical to have a non-painful build/deploy process. Bad things will make it to Production. Guaranteed. The real question isn't how to prevent it, but how to respond to it.

如果有什么区别的话，这就是为什么拥有一个不痛苦的构建/部署过程是至关重要的一个主要例子。糟糕的事情会让它变成现实。保证。真正的问题不是如何预防，而是如何应对。